GPU VulnDB

Database/NVIDIA / GPU stack

Linux kernel drm/xe: userptr inject path takes notifier_lock for read, tripping a GPU SVM lock assertion

CVE-2026-80606NVIDIA / GPU stackcurated

Impact

On Intel Xe GPU driver builds, xe_pt_svm_userptr_pre_commit() ran the userptr invalidation-injection path while holding the SVM notifier_lock for read, while drm_gpusvm_unmap_pages() assumes the caller holds it for write. The result is a lock-mode violation reachable from a VM bind ioctl, producing a kernel warning and unsound locking around GPU shared-virtual-memory page unmapping. The important qualifier is in the fix itself: this only occurs when CONFIG_DRM_XE_USERPTR_INVAL_INJECT=y, a fault-injection test option, and the upstream change states production builds with that option off keep the previous behaviour bit-for-bit. Stock distribution and vendor kernels do not enable that option, so for almost every operating fleet this is a test-configuration bug rather than a live exposure - verify your own kernel config before scheduling anything.

Who can reach it

Local user with access to an Intel Xe GPU device node who can issue a VM bind ioctl, and only on a kernel built with the fault-injection Kconfig enabled. No remote reach.

What to do

Check whether your kernel sets CONFIG_DRM_XE_USERPTR_INVAL_INJECT; if it is not set, no action is required. If you build kernels with fault injection enabled (CI or driver-development machines), take a stable kernel containing the fix and reboot those hosts, draining GPU work first. The record lists the stable commits but no fixed release number, so confirm against your kernel tree rather than assuming a version.

References

Related entries

All NVIDIA / GPU stack entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.