CVE-2026-80701

Niskie ryzyko· EPSS 6%

Opublikowano: 28/08/2026(UTC)Przetłumaczono: 28/08/2026(UTC)NVD NIST

Prawdopodobieństwo exploitacji (EPSS)

Niskie ryzyko

0.17%

Percentyl 6 - wyżej niż 6% wszystkich znanych CVE

Streszczenie

W jądrze Linux w sterowniku DRM vmwgfx odkryto podatność polegającą na braku walidacji rozmiaru kursora dla ścieżki MOB (SVGA_CAP2_CURSOR_MOB). Atakujący z uprawnieniami DRM master może przez ioctl DRM_IOCTL_MODE_CURSOR2 ustawić bardzo duży kursor, co prowadzi do wywołania vmw_bo_map_and_cache(NULL) i awarii systemu (oops).

Ocena ryzyka

Ryzyko obejmuje lokalną odmowę usługi (DoS) — atakujący z dostępem do /dev/dri może doprowadzić do zawieszenia lub awarii jądra, co wpływa na dostępność systemu.

Rekomendacja

Zaleca się natychmiastowe zastosowanie łatki z jądra Linux, która ogranicza rozmiary kursora w funkcji atomic_check oraz poprawnie obsługuje błędy w prepare_fb. Należy zaktualizować system do wersji jądra zawierającej poprawkę.

Inne podatności w Linux kernel

Zobacz wszystkie

Oryginalny opis (angielski, źródło NVD)

In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: enforce cursor size limits for MOB cursors vmw_cursor_plane_atomic_check() bounds cursor width and height only on the legacy update path; the SVGA_CAP2_CURSOR_MOB path -- the default on modern hosts -- accepts any size. When the requested size exceeds SVGA_REG_CURSOR_MAX_DIMENSION or SVGA_REG_MOB_MAX_SIZE, vmw_cursor_mob_get() returns -EINVAL and leaves vps->cursor.mob NULL. Its return value is then discarded in vmw_cursor_plane_prepare_fb(), so the subsequent vmw_cursor_update_mob() calls vmw_bo_map_and_cache(NULL) and oopses inside vmw_bo_map_and_cache_size() on the tbo.base.size load. Reachable from any DRM master via DRM_IOCTL_MODE_CURSOR2 with a sufficiently large width or height (e.g. cursor_max_dim + 1). Reject oversized cursors in atomic_check for both MOB-backed cursor update types. The MOB byte-size limit only applies to the SVGA_CAP2_CURSOR_MOB path (vmw_cursor_mob_size() returns 0 for GB_ONLY); compute the required MOB size in 64-bit to avoid overflow when very large dimensions are requested. In prepare_fb only call vmw_cursor_mob_get()/_map() for VMW_CURSOR_UPDATE_MOB -- the GB_ONLY path uses bo->map.virtual directly and would otherwise be silently downgraded to NONE on hosts without SVGA_CAP2_CURSOR_MOB (where vmw_cursor_mob_get() always returns -EINVAL). Degrade the update to NONE if vmw_cursor_mob_get() or vmw_cursor_mob_map() fails so the update path does not run with a NULL backing MOB.