Cloudanix VulnDB

CVE-2026-98510

None

CVSS

—

EPSS

0.2%

Published

Oct 18, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A timing flaw in graphics memory cleanup on certain Linux systems can crash the machine or let a local attacker gain full control.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Denial Of Service
Component
OS kernel
Class
Race Condition
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Race condition in xe_vm_close_and_put() destroys vm->pt_root before contested VMAs are unlinked, allowing concurrent xe_bo_trigger_rebind() to dereference a NULL pt->level in xe_pt_zap_ptes() during eviction.

Why it matters to the business

Kernel crashes or potential local privilege escalation on systems using affected Intel Xe graphics drivers, causing downtime and possible full system compromise; urgency remains low given five-day publication age and minimal EPSS.

How an attack unfolds

An attacker with local access triggers concurrent VMA close and buffer-object eviction operations to hit the window where page-table roots are already freed, resulting in NULL pointer dereference during PTE zapping.

How to fix it

Upgrade to a kernel containing commit c2863648959489767f08892fd6e90577d2ea0b6a or later; apply vendor backports that defer xe_vm_free_scratch() and xe_vm_pt_destroy() until after all contested VMAs are destroyed.

How to confirm the fix worked

Confirm kernel version includes the referenced commit; reproduce the race with concurrent VMA close and eviction workloads while monitoring for NULL dereference in xe_pt_zap_ptes(); review dmesg for the specific call trace.

Typical attack path

  1. Open and map external-BO VMAs in fault mode
  2. Initiate xe_vm_close_and_put() on the VM
  3. Concurrently trigger eviction of the shared buffer object
  4. xe_vm_invalidate_vma() walks VMAs after pt_root is NULL
  5. xe_pt_zap_ptes() dereferences NULL pt->level

How to detect it

Search kernel logs and crash dumps for NULL pointer dereference traces containing xe_pt_zap_ptes, xe_vm_invalidate_vma, or xe_bo_trigger_rebind; correlate with graphics driver activity and contested VMA operations.

What your security team should do

  • Prioritize kernel updates on all systems exposing Intel Xe graphics within the next 30 days
  • Enable kernel panic-on-oops and monitor for related crashes in production fleets
  • Restrict untrusted local code execution on multi-user or container hosts until patched

The record

In the Linux kernel, the following vulnerability has been resolved: drm/xe/vm: nuke PTs only after unlinking contested VMAs In xe_vm_close_and_put(), external-BO VMAs are queued on the contested list for deferred destruction via xe_vma_destroy_unlocked(). However, xe_vm_pt_destroy() was previously invoked before processing contested VMAs, destroying vm->pt_root while those VMAs were still linked to their respective buffer objects (vm_bo->list.gpuva). If a concurrent thread evicts one of those shared buffer objects, xe_bo_trigger_rebind() holding only bo->resv walks the BO's VMAs and, in fault mode, calls xe_vm_invalidate_vma() -> xe_pt_zap_ptes(). Because vm->pt_root[tile->id] is already NULL, dereferencing pt->level causes a NULL ptr deref. Fix this by deferring xe_vm_free_scratch() and xe_vm_pt_destroy() until after all contested VMAs have been unlinked and destroyed. User is reporting hitting a NULL ptr deref in xe_pt_zap_ptes(), which could be explained by this race. (cherry picked from commit c2863648959489767f08892fd6e90577d2ea0b6a)

Affected packages

Ecosystem Package Introduced Fixed