CVE-2026-80701 in Linux
Zusammenfassung
von VulDB • 28.08.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
drm/vmwgfx: Erzwingen von Cursor-Größenbeschränkungen für MOB-Cursor
vmw_cursor_plane_atomic_check() beschränkt die Breite und Höhe des Cursors nur im Legacy-Aktualisierungspfad; der SVGA_CAP2_CURSOR_MOB-Pfad – der Standard auf modernen Hosts – akzeptiert jede beliebige Größe. Wenn die angeforderte Größe SVGA_REG_CURSOR_MAX_DIMENSION oder SVGA_REG_MOB_MAX_SIZE überschreitet, gibt vmw_cursor_mob_get() -EINVAL zurück und lässt vps->cursor.mob NULL. Sein Rückgabewert wird dann in vmw_cursor_plane_prepare_fb() verworfen, sodass die nachfolgenden Aufrufe von vmw_cursor_update_mob() vmw_bo_map_and_cache(NULL) ausführen und im vmw_bo_map_and_cache_size()-Aufruf beim Laden von tbo.base.size abstürzen (oops).
Erreichbar über jeden DRM-Master mittels DRM_IOCTL_MODE_CURSOR2 mit einer ausreichend großen Breite oder Höhe (z. B. cursor_max_dim + 1).
Verwerfen von übergroßen Cursoren im atomic_check für beide MOB-gestützten Cursor-Aktualisierungstypen. Die Byte-Größenbeschränkung für MOBs gilt nur für den SVGA_CAP2_CURSOR_MOB-Pfad (vmw_cursor_mob_size() gibt 0 zurück, wenn GB_ONLY); berechnen Sie die erforderliche MOB-Größe in 64-Bit, um einen Überlauf bei sehr großen Dimensionen zu vermeiden.
Rufen Sie in prepare_fb nur vmw_cursor_mob_get()/_map() für VMW_CURSOR_UPDATE_MOB auf – der GB_ONLY-Pfad verwendet bo->map.virtual direkt und würde andernfalls ohne Warnung auf NONE herabgestuft werden, wenn Hosts keinen SVGA_CAP2_CURSOR_MOB unterstützen (wo vmw_cursor_mob_get() immer -EINVAL zurückgibt). Führen Sie eine Herabstufung der Aktualisierung auf NONE durch, wenn vmw_cursor_mob_get() oder vmw_cursor_mob_map() fehlschlagen, damit der Aktualisierungspfad nicht mit einer NULL-MOB-Unterstützung ausgeführt wird.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.