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)
Published: 2026-08-28
Score: n/a
EPSS: n/a
KEV: No
Impact: n/a
Action: n/a
AI Analysis

Impact

The vulnerability arises from a mis‑managed lock in the Linux DRM Xe userptr module. When the CONFIG_DRM_XE_USERPTR_INVAL_INJECT option is enabled, the commit path acquires the notifier_lock for reading, but later code paths assume the lock is held for write. This incorrect assumption triggers an assertion failure that can cause a kernel panic, resulting in a denial of service. The flaw resides in improper lock usage (a race condition) and could be leveraged by anyone able to trigger the injection sequence.

Affected Systems

All Linux kernel builds that enable the CONFIG_DRM_XE_USERPTR_INVAL_INJECT configuration are affected. Production kernels that do not enable this option remain unaffected. The issue applies to any platform running the kernel before it is patched with the commit that adds xe_pt_svm_userptr_notifier_lock() and related fixes.

Risk and Exploitability

The CVSS score is not available, and the vulnerability is not listed in CISA's KEV catalog. The EPSS score is not available, so the exact likelihood of exploitation is unclear. However, the flaw can lead to a kernel panic, a high‑impact outcome. The likely attack vector is local or via privileged code that can trigger the invalidation path; a remote attacker would need significant privilege or kernel module injection to exploit it.

Generated by OpenCVE AI on August 28, 2026 at 11:40 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Update to a Linux kernel version that contains the commit which adds xe_pt_svm_userptr_notifier_lock() and adjusts the lock handling for the injection path.
  • If a kernel update is not possible, manually patch the kernel source to acquire the notifier_lock for write during xe_pt_svm_userptr_pre_commit and replace the assertion with xe_svm_assert_held_read_or_inject_write().
  • As a temporary measure, disable the CONFIG_DRM_XE_USERPTR_INVAL_INJECT option so the injection code path is not compiled into the kernel.

Generated by OpenCVE AI on August 28, 2026 at 11:40 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Fri, 28 Aug 2026 07:30:00 +0000

Type Values Removed Values Added
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)
Title drm/xe/userptr: Hold notifier_lock for write on inject test path
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-08-28T06:48:30.960Z

Reserved: 2026-08-26T14:34:25.772Z

Link: CVE-2026-80606

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-08-28T08:16:44.573

Modified: 2026-08-28T08:16:44.573

Link: CVE-2026-80606

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-08-28T10:00:06Z

Weaknesses

No weakness.