CVE-2026-98510 in Linux
Summary
by MITRE • 10/18/2026
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)
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/18/2026
The Linux kernel's DRM Xe driver contains a race condition vulnerability within the virtual memory management subsystem that leads to a NULL pointer dereference. This flaw occurs during the cleanup phase of external buffer object virtual memory areas, specifically in the xe_vm_close_and_put function where contested VMAs are queued for deferred destruction via xe_vma_destroy_unlocked. The core technical issue stems from an incorrect ordering of operations: the kernel was invoking xe_vm_pt_destroy to tear down page table structures before ensuring that all contested VMAs had been fully unlinked and destroyed. Consequently, the vm->pt_root structure is freed while buffer objects still maintain active links to their respective GPU virtual address ranges through the vm_bo list.
This timing error creates a critical window for concurrent execution paths to trigger a crash. When another thread attempts to evict one of these shared buffer objects, it triggers xe_bo_trigger_rebind which holds only the reservation lock on the buffer object. This function walks the associated VMAs and, in fault mode, calls xe_vm_invalidate_vma followed by xe_pt_zap_ptes to update page table entries. Because the parent page table root has already been destroyed due to the premature call to xe_vm_pt_destroy, any attempt to dereference pt->level results in accessing a NULL pointer. This race condition can lead to kernel panics or system instability depending on memory layout and timing conditions during high-concurrency graphics workloads.
From a security perspective, this vulnerability is classified under CWE-416 which addresses Use After Free scenarios where resources are accessed after they have been freed. The operational impact includes denial of service through kernel crashes, potentially affecting the stability of systems running heavy graphical or compute-intensive tasks using Intel Xe drivers. Although typically resulting in local denial of service rather than privilege escalation due to the nature of NULL pointer dereferences in modern kernels with KASLR and other mitigations, it remains a significant reliability issue that can be exploited by unprivileged users to disrupt system availability if they can trigger concurrent buffer object eviction during VM teardown sequences.
The fix involves reordering the cleanup logic within xe_vm_close_and_put to ensure that all contested VMAs are properly unlinked and destroyed before invoking xe_vm_free_scratch and xe_vm_pt_destroy. This ensures that no active references remain in the buffer object lists when page table structures are deallocated, thereby eliminating the race condition window. Mitigation strategies for system administrators include applying kernel updates containing this patch or disabling specific Xe driver features if immediate update is not possible. Monitoring logs for NULL pointer dereference traces can help identify affected systems prior to remediation. This issue aligns with ATT&CK techniques related to resource hijacking and denial of service, highlighting the importance of proper synchronization in concurrent memory management operations within kernel space drivers.