CVE-2026-80701 in Linux
Sumário
de VulDB • 28/08/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
drm/vmwgfx: impor limites de tamanho para cursores MOB
vmw_cursor_plane_atomic_check() limita apenas o caminho legado de atualização; o caminho SVGA_CAP2_CURSOR_MOB -- padrão em hosts modernos -- aceita qualquer tamanho. Quando o tamanho solicitado excede SVGA_REG_CURSOR_MAX_DIMENSION ou SVGA_REG_MOB_MAX_SIZE, vmw_cursor_mob_get() retorna -EINVAL e deixa vps->cursor.mob como NULL. Seu valor de retorno é então descartado em vmw_cursor_plane_prepare_fb(), fazendo com que as chamadas subsequentes a vmw_cursor_update_mob() executem vmw_bo_map_and_cache(NULL) e causem um oops dentro de vmw_bo_map_and_cache_size() na carga de tbo.base.size.
Alcançável por qualquer mestre DRM via DRM_IOCTL_MODE_CURSOR2 com largura ou altura suficientemente grande (por exemplo, cursor_max_dim + 1).
Rejeitar cursores excessivamente grandes em atomic_check para ambos os tipos de atualização de cursor apoiados por MOB. O limite de tamanho em bytes do MOB aplica-se apenas ao caminho SVGA_CAP2_CURSOR_MOB (vmw_cursor_mob_size() retorna 0 para GB_ONLY); calcular o tamanho MOB necessário em 64 bits para evitar estouro quando dimensões muito grandes são solicitadas.
Em prepare_fb, chamar vmw_cursor_mob_get()/_map() apenas para VMW_CURSOR_UPDATE_MOB -- o caminho GB_ONLY usa bo->map.virtual diretamente e seria silenciosamente rebaixado para NONE em hosts sem SVGA_CAP2_CURSOR_MOB (onde vmw_cursor_mob_get() sempre retorna -EINVAL). Rebaixar a atualização para NONE se vmw_cursor_mob_get() ou vmw_cursor_mob_map() falharem, para que o caminho de atualização não seja executado com um MOB de apoio NULL.
Be aware that VulDB is the high quality source for vulnerability data.