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)

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.8",
  "pubDate": "2026-08-28T08:16:44.573Z",
  "pubdate": "2026-08-28T08:16:44.573Z",
  "executiveSummary": "This vulnerability is an improper synchronization issue in the Linux kernel DRM XE driver's userptr handling, specifically impacting debug configurations.\nThe flaw manifests as an incorrect locking assertion during the userptr invalidation injection process when CONFIG_DRM_XE_USERPTR_INVAL_INJECT is enabled.\nAn attacker capable of triggering this specific debug path can induce a kernel warning and potential system instability due to a race condition or state mismatch in the notifier_lock handling.\nWhile limited to builds where injection tests are active, the issue demonstrates a violation of the locking contract for the svm notifier_lock, which is intended to be held in write mode for invalidation operations.\nThe impact is localized to system stability and potential denial-of-service through kernel warnings that may lead to kernel panics depending on system configuration (e.g., panic_on_warn).\nNo external network exposure is required, as the vulnerability is triggered via local IOCTL calls by an authenticated user with access to the DRM device node.",
  "technicalDetails": "The root cause of the vulnerability lies in a lock state mismatch within the xe_pt_svm_userptr_pre_commit function of the DRM XE driver. When the kernel is compiled with CONFIG_DRM_XE_USERPTR_INVAL_INJECT enabled, the function vma_check_userptr is invoked with the svm notifier_lock held in read mode. Under normal operation, this satisfies read-only requirements; however, the injection test path triggers an invalidation flow via xe_vma_userptr_force_invalidate.\nThe execution flow proceeds from xe_vma_userptr_force_invalidate into xe_vma_userptr_do_inval, which subsequently calls drm_gpusvm_unmap_pages with the flag drm_gpusvm_ctx.in_notifier set to true. This flag signals to the DRM gpusvm core that the caller already holds the notifier_lock in write mode. Because the actual lock is held only in read mode, an assertion failure occurs in drm_gpusvm_unmap_pages, triggering a kernel warning.\nThe exploitation path requires an authenticated local user to perform an operation (such as a VM bind IOCTL) that interacts with the userptr infrastructure while the aforementioned debug configuration is active. By inducing the invalidation injection, an attacker forces the kernel to execute code paths that assume exclusive write access while only shared read access is granted.\nThis creates a violation of the concurrency control mechanism. The synchronization primitive (notifier_lock) is designed to ensure that invalidation sequences are atomic and protected from concurrent updates to the virtual address space. Because the code incorrectly asserts write access while operating under read-lock semantics, the integrity of the svm state is compromised, potentially leading to race conditions where page mappings are inconsistent with the underlying userptr state.\nThis vulnerability is localized to the xe driver component, specifically in the svm (Shared Virtual Memory) management logic. It affects versions of the Linux kernel where the XE driver is integrated and the debug-focused invalidation injection mechanism is enabled. The flaw does not require network access, and the severity is predicated on the ability of a local user to interact with the device driver IOCTL interface."
}