NULL Pointer Dereference Affecting kernel-rt-64k-debug package, versions *
Threat Intelligence
The probability is the direct output of the EPSS model, and conveys an overall sense of the threat of exploitation in the wild. The percentile measures the EPSS probability relative to all known EPSS scores. Note: This data is updated daily, relying on the latest available EPSS model version. Check out the EPSS documentation for more details.
Do your applications use this vulnerable package?
In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.
Test your applications- Snyk IDSNYK-RHEL10-KERNELRT64KDEBUG-19453717
- published1 Sept 2026
- disclosed28 Aug 2026
Introduced: 28 Aug 2026
NewCVE-2026-80701 (opens in a new tab)How to fix?
There is no fixed version for RHEL:10 kernel-rt-64k-debug.
NVD Description
Note: Versions mentioned in the description apply only to the upstream kernel-rt-64k-debug package and not the kernel-rt-64k-debug package as distributed by RHEL.
See How to fix? for RHEL:10 relevant fixed versions and status.
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.
References
- https://bugzilla.redhat.com/show_bug.cgi?id=2525490
- https://access.redhat.com/security/cve/CVE-2026-80701
- https://git.kernel.org/stable/c/1eb4f796695be39e0b5c4383350033ced9ade703
- https://git.kernel.org/stable/c/9109b7935b9c058b75348610ef8437c52f9020e3
- https://git.kernel.org/stable/c/d5ed8749168ad13c0dbaa8300f68d854b6076966