Cloudanix VulnDB

CVE-2026-68264

High · 7.8

CVSS

7.8

EPSS

0.1%

Published

Aug 10, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A flaw in the graphics driver can let a logged-in user crash the system or corrupt memory, which may allow them to gain higher privileges.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
Low
Impact
Full Compromise
Component
OS kernel
Class
Buffer Overflow
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Failure to reset current_op (and related flags) in xe_pt_update_ops_init allows repeated bind_op_prepare calls during vm_bind retry loops to perform out-of-bounds writes into SLUB-poisoned memory, leading to use-after-free when later code dereferences corrupted pt_op structures.

Why it matters to the business

Local users can trigger kernel crashes or memory corruption on systems using the affected Intel Xe graphics driver, potentially causing denial of service or local privilege escalation with no network access required.

How an attack unfolds

An attacker with local access triggers repeated retries in the drm_exec_until_all_locked loop (via lock contention or OOM eviction) on the vm_bind path; each retry increments current_op past the allocated array size, corrupting adjacent memory and causing a later UAF crash or exploitable write during page table migration.

How to fix it

Apply the upstream fix that resets current_op, needs_svm_lock and needs_invalidation inside xe_pt_update_ops_init; rebuild and deploy the patched kernel. Monitor stable backports for distribution kernels.

How to confirm the fix worked

Confirm the presence of the reset statements for current_op, needs_svm_lock and needs_invalidation in xe_pt_update_ops_init(); run kernel regression tests exercising vm_bind under contention and OOM conditions.

Typical attack path

  1. Obtain local shell on affected Linux system
  2. Issue repeated vm_bind operations that induce lock contention or OOM eviction
  3. Force xe_pt_update_ops_prepare to run multiple times without reset
  4. Trigger out-of-bounds write into SLUB memory
  5. Force subsequent xe_migrate_update_pgtables_cpu execution to dereference corrupted data

How to detect it

Search kernel logs for repeated drm_exec_retry_on_contention or xe_validation_retry_on_oom messages followed by SLUB or UAF oops in xe_migrate_update_pgtables_cpu; inspect crash dumps for corrupted pt_op structures.

What your security team should do

  • Prioritize kernel updates on all systems exposing the Xe driver
  • Restrict local user access until patched kernels are deployed
  • Add kernel memory corruption monitoring to existing endpoint detection

The record

In the Linux kernel, the following vulnerability has been resolved: drm/xe/pt: Reset current_op in xe_pt_update_ops_init() xe_pt_update_ops_init() fails to reset current_op to 0. On the vm_bind path, ops_execute() calls xe_pt_update_ops_prepare() inside the xe_validation_guard() / drm_exec_until_all_locked() loop. When that loop retries due to lock contention or OOM eviction (drm_exec_retry_on_contention() / xe_validation_retry_on_oom()), xe_pt_update_ops_prepare() runs again on the same vops, and each call to bind_op_prepare() increments current_op without resetting it. After N retries current_op exceeds the array size allocated by xe_vma_ops_alloc(), causing an out-of-bounds write into SLUB-poisoned memory and a subsequent UAF crash in xe_migrate_update_pgtables_cpu() when reading the corrupted pt_op->bind. Also reset needs_svm_lock and needs_invalidation which are derived in the same prepare pass and would otherwise cause wrong migrate ops selection and redundant TLB invalidation on retry. Fix this by resetting current_op, needs_svm_lock and needs_invalidation in xe_pt_update_ops_init(). v2 (Matt): - Add details in commit message. - Add Fixes tag and Cc to stable@vger.kernel.org (cherry picked from commit 046045543e530605c441063535e7dca0075369a6)

Affected packages

Ecosystem Package Introduced Fixed