ZeroHour

CVE-2026-80606

niche

Improper lock-mode assertion in Linux kernel DRM Xe userptr invalidation path

CVSS 3.1
7.8 high
EPSS
<1%p3
Published
()
Modified
AI analysis

CVE-2026-80606 is a locking-mode error in the Linux kernel's DRM Xe GPU driver (drm/xe): when the debug/test option CONFIG_DRM_XE_USERPTR_INVAL_INJECT is enabled, the xe_pt_svm_userptr_pre_commit() path takes the SVM notifier lock for read, while the injected userptr invalidation path (xe_vma_userptr_force_invalidate -> drm_gpusvm_unmap_pages) assumes the lock is held for write, tripping a kernel assertion (WARNING) during GPU virtual-memory bind operations. It is triggered locally via xe_vm_bind_ioctl() by any process performing an Xe VM bind on a kernel built with that test option. The observed symptom is a kernel WARNING (lock-mode assertion); the CVSS 3.1 score of 7.8 (AV:L/AC:H/PR:L/UI:N/S:C, high C/I/A) indicates potential for broader impact, but the fix description documents no privilege escalation or memory corruption beyond the assertion. Only kernels that include the Xe driver and are built with CONFIG_DRM_XE_USERPTR_INVAL_INJECT=y are affected (typically test, CI, and developer builds); production builds with the option disabled keep identical behavior and are unaffected. There is no public PoC, the issue is not in CISA KEV, and EPSS is 0.1% (3rd percentile), so no exploitation is known.

What to do: Check whether your kernel configuration enables CONFIG_DRM_XE_USERPTR_INVAL_INJECT; if it does, update to a kernel that includes the fix (commit 80ccbd97ffee or its backport) or disable that option, since production builds with the option off need no action. Operators of standard distribution kernels with the Xe driver should confirm their config does not enable the injection option. Monitor vendor advisories for the version that picks up the backported fix.

Affected
Linux kernel, DRM Xe GPU driver (drm/xe with drm_gpusvm helper)
Estimated exposure
nichelikely only thousands of systems or fewer (mainly developer, CI, and test kernels with the Xe driver and a rarely enabled debug-injection Kconfig) — The flaw only manifests when CONFIG_DRM_XE_USERPTR_INVAL_INJECT=y, a test-injection option that standard distribution and production kernel configs generally do not enable, so the affected population is limited to test/debug builds of…

Order-of-magnitude estimate by the model from install counts, market share and public scan data it knows; verify before quoting.

Description

In the Linux kernel, the following vulnerability has been resolved: drm/xe/userptr: Hold notifier_lock for write on inject test path When CONFIG_DRM_XE_USERPTR_INVAL_INJECT=y, xe_pt_svm_userptr_pre_commit() runs vma_check_userptr() with the svm notifier_lock taken for read. The test injection causes vma_check_userptr() to call xe_vma_userptr_force_invalidate(), which feeds into xe_vma_userptr_do_inval() with drm_gpusvm_ctx.in_notifier=true. That flag tells drm_gpusvm_unmap_pages() the caller already holds notifier_lock for write and only asserts the mode. Because the caller actually holds it for read, the assertion fires: WARNING: drivers/gpu/drm/drm_gpusvm.c:1669 at \ drm_gpusvm_unmap_pages+0xd4/0x130 [drm_gpusvm_helper] Call Trace: xe_vma_userptr_do_inval+0x40d/0xfd0 [xe] xe_vma_userptr_invalidate_pass1+0x3e6/0x8d0 [xe] xe_vma_userptr_force_invalidate+0xde/0x290 [xe] vma_check_userptr.constprop.0+0x1c6/0x220 [xe] xe_pt_svm_userptr_pre_commit+0x6a3/0xc60 [xe] ... xe_vm_bind_ioctl+0x3a0a/0x4480 [xe] Acquire notifier_lock for write in pre-commit when the inject Kconfig is enabled, via new helpers xe_pt_svm_userptr_notifier_lock()/_unlock(). Rename xe_svm_assert_held_read() to xe_svm_assert_held_read_or_inject_write() so it asserts the correct mode under each build configuration. Production builds (CONFIG_DRM_XE_USERPTR_INVAL_INJECT=n) keep the existing read-mode behavior bit-for-bit. (cherry picked from commit 80ccbd97ffee8ad2e73167d826fe7be548364365)

Vector
CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H

In the news

No ingested article mentions this CVE yet.