Cloudanix VulnDB

CVE-2026-98999

High · 7.8

CVSS

7.8

EPSS

0.2%

Published

Oct 23, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A graphics driver bug can let a local user corrupt kernel memory, potentially crashing the system or gaining higher privileges.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
Low
Impact
Full Compromise
Component
OS kernel
Class
Use After Free
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

Stale pinned_link list entry remains after final pin_count 1->0 transition performed via fb unpin path, causing list corruption and use-after-free when the freed bo is later traversed or spliced.

Why it matters to the business

Kernel memory corruption on systems using Intel Xe graphics can lead to crashes or local privilege escalation; recent publication and local attack vector require prompt kernel updates on affected distributions.

How an attack unfolds

An attacker with local access triggers repeated external pin/unpin (dma-buf) interleaved with framebuffer pin/unpin sequences on the same bo so that xe_bo_unpin_external leaves the entry while the subsequent fb unpin performs the true final unpin without removing it; later free of the bo followed by list walk or splice triggers the use-after-free.

How to fix it

Upgrade to a kernel containing the fix that moves pinned_link removal into xe_bo_account_unpin and removes the redundant list_del_init calls; apply the cherry-picked commit or later equivalent as soon as vendor packages are available.

How to confirm the fix worked

Confirm the presence of xe_bo_account_unpin list_del_init logic or absence of the stale-link path in xe_bo_unpin_external; test by exercising mixed external/fb pin/unpin workloads and verifying no list corruption on object free.

Typical attack path

  1. Obtain local user privileges on a system with Intel Xe GPU
  2. Create a buffer object pinned both externally and as a display framebuffer
  3. Perform external unpin while fb pin_count remains >1
  4. Trigger final fb unpin that decrements pin_count to zero without touching pinned_link
  5. Free the bo and induce subsequent pinned list walk or splice to trigger UAF

How to detect it

Review kernel logs for list corruption warnings or oops during pinned list operations after bo free; correlate with processes performing mixed dma-buf and framebuffer operations on Xe GPUs.

What your security team should do

  • Prioritize kernel updates for all systems exposing Intel Xe graphics within the next patching cycle
  • Monitor upstream stable and distribution kernel changelogs for the referenced commit
  • Restrict unprivileged access to graphics and dma-buf interfaces on high-risk hosts until patched

The record

In the Linux kernel, the following vulnerability has been resolved: drm/xe: Fix stale pinned_link entry when fb-pin performs the final unpin xe_bo_pin_external() and xe_bo_unpin_external() maintain the bo's pinned_link list membership in xe->pinned.late.external, based on whether the current call is the outermost pin or the final unpin. However, the same external bo's pin_count can also be raised and lowered directly by __xe_pin_fb_vma()/__xe_unpin_fb_vma(), which pin the bo as a display scanout buffer without going through xe_bo_pin_external()/xe_bo_unpin_external() at all, and have no notion of, or ownership over, pinned_link. If a bo is pinned both externally (e.g. dma-buf export) and as an fb, and the external unpin happens first, xe_bo_unpin_external() correctly observes pin_count > 1 and leaves the bo on pinned_link. When the fb unpin later performs the true last unpin (pin_count 1 -> 0), it never touches pinned_link, leaving the bo linked on xe->pinned.late.external indefinitely. Once the bo is subsequently freed, this stale list entry points into freed memory, corrupting the list and risking a use-after-free the next time the list is walked or spliced. The backup object pin/unpin sites in xe_bo_notifier_prepare_pinned()/ xe_bo_notifier_unprepare_pinned() have the same bypass characteristic, though they never add their bo to a pinned list, so are not affected by this particular list-corruption issue. Move the pinned_link removal into xe_bo_account_unpin(), which already runs on every unpin path (kernel, external, framebuffer, backup object) right before the true 1 -> 0 pin_count transition. Since list_del_init() only operates on the node itself, this removal is list-agnostic and safe to perform regardless of which list (external or kernel_bo_present) the bo happens to be linked on, or which code path is performing the final unpin. Drop the now-redundant explicit list_del_init() calls in xe_bo_unpin_external() and xe_bo_unpin(). v2: - New patch v3: - Rebased on changes to previous patch. (cherry picked from commit ca58d36a1f93af586ee93b340c9f9fd81312cc01)

Affected packages

Ecosystem Package Introduced Fixed