CVE-2026-80701 in Linux
요약
\~에 의해 VulDB • 2026. 08. 28.
리눅스 커널에서 다음 취약점이 해결되었습니다:
drm/vmwgfx: MOB 기반 커서의 크기 제한 강제 적용
vmw_cursor_plane_atomic_check() 함수는 레거시 업데이트 경로에서만 커서 너비와 높이에 대한 경계를 확인합니다. 반면 SVGA_CAP2_CURSOR_MOB 경로(현대 호스트의 기본값)는 모든 크기를 허용합니다. 요청된 크기가 SVGA_REG_CURSOR_MAX_DIMENSION 또는 SVGA_REG_MOB_MAX_SIZE를 초과하면 vmw_cursor_mob_get()은 -EINVAL를 반환하고 vps->cursor.mob을 NULL로 남깁니다. 이후 vmw_cursor_plane_prepare_fb()에서 이 반환값이 무시되므로, 후속 호출인 vmw_cursor_update_mob()는 vmw_bo_map_and_cache(NULL)을 호출하며 tbo.base.size 로드 시 vmw_bo_map_and_cache_size() 내부에서oops(커널 패닉)를 발생시킵니다.
DRM master라면 누구나 DRM_IOCTL_MODE_CURSOR2 인터페이스를 통해 충분히 큰 너비 또는 높이(예: cursor_max_dim + 1)로 이 취약점에 접근할 수 있습니다.
MOB 기반 커서 업데이트 유형 모두에 대해 atomic_check에서 크기가 초과하는 커서를 거부합니다. MOB 바이트 크기 제한은 SVGA_CAP2_CURSOR_MOB 경로에만 적용됩니다(SVGA_CAP2_CURSOR_MOB가 아닌 GB_ONLY 경로의 경우 vmw_cursor_mob_size()는 0을 반환함). 매우 큰 차원이 요청될 때 오버플로우를 피하기 위해 필요한 MOB 크기를 64비트로 계산합니다.
prepare_fb 단계에서는 VMW_CURSOR_UPDATE_MOB 경로에 대해서만 vmw_cursor_mob_get()/_map()을 호출합니다. GB_ONLY 경로는 bo->map.virtual을 직접 사용하며, SVGA_CAP2_CURSOR_MOB가 없는 호스트(여기서 vmw_cursor_mob_get()은 항상 -EINVAL를 반환함)에서는 그렇지 않으면 묵시적으로 NONE으로 다운그레이드됩니다. vmw_cursor_mob_get() 또는 vmw_cursor_mob_map() 실패 시 업데이트를 NONE으로 강등하여, NULL로 설정된 MOB 백킹을 가진 상태로 업데이트 경로가 실행되지 않도록 합니다.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.