Skip to main content

Linux Kernel EUVDEUVD-2026-108793

| CVE-2026-98999 HIGH
2026-10-23 Linux GHSA-7j8x-2fgw-fvx8
7.8
CVSS 3.1 · Vendor: Linux
View

Attack ChainAIDerived

Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain

  1. Access
    Gain local access with GPU/display privileges
  2. Delivery
    Pin a buffer object both via dma-buf export and as a scanout framebuffer
  3. Exploit
    Release the external pin before the framebuffer unpin
  4. Execution
    Framebuffer performs final unpin leaving a stale pinned_link node after free
  5. Impact
    Trigger use-after-free when the pinned list is walked or spliced

Vulnerability Assessment

Exploitation Conditions

Exploitation requires a system running the Intel Xe GPU driver (drm/xe) and a buffer object that is pinned BOTH externally (e.g. via dma-buf export through xe_bo_pin_external) AND as a display scanout framebuffer via __xe_pin_fb_vma, with the external unpin occurring before the framebuffer performs the final pin_count 1->0 transition - that specific ordering is what leaves the stale pinned_link node. The attacker must therefore be a local user with the ability to allocate GPU buffer objects, perform dma-buf export, and drive display scanout pinning. Limiting factors: AV:L means no remote reach; PR:L means some local GPU/display privilege is needed; the bug only manifests on hardware/configurations using the relatively new Xe driver, and only when the dual-pin plus reverse-unpin sequence is arranged, so it will not trigger in default idle operation.

Impact

This is a local-privilege memory-safety flaw (use-after-free / list corruption) in the Linux kernel's drm/xe GPU driver, scored CVSS 7.8 with vector AV:L/AC:L/PR:L/UI:N and full C:H/I:H/A:H impact - consistent with a kernel UAF that can corrupt the xe->pinned.late.external list and be leveraged toward kernel code execution or privilege escalation. The exploitation signals, however, point to low real-world urgency rather than an emergency: EPSS is only 0.22% (12th percentile), there is no CISA KEV listing, and no public exploit or PoC is present in the input (the three git.kernel.org links are stable-tree patch commits, not exploit code). The vuln.today Decision label is 'this_week', which aligns with a patch-available, locally-exploitable kernel bug that merits routine stable-update cadence rather than drop-everything response. The CVSS vector (AV:L) and the description agree that this is local-only and requires the attacker to already have GPU/display access, so there is no network or unauthenticated exposure. No SSVC automatable/technical-impact fields were supplied, and CWE is N/A, so the UAF classification is inferred from the description, not vendor-assigned. Net: a genuine but not urgent fix-on-schedule kernel bug - high CVSS severity, low current exploitation probability, and a constrained local attack surface.

Exploit ScenarioDerived

A local user on a system with an Intel Xe GPU allocates a buffer object, pins it both as a dma-buf export (external pin) and as a display scanout framebuffer, then releases the external pin first so the buffer stays linked on the kernel's external pinned list; when the framebuffer unpin later performs the true final unpin without touching that list, the buffer is freed while still linked, leaving a dangling node. The next walk or splice of the pinned list dereferences freed memory, giving a use-after-free the attacker can groom toward kernel memory corruption or privilege escalation. No public exploit or PoC is identified in the available data.

This Week Schedule remediation this week. Why: HIGH severity (CVSS 7.0-8.9).
Patch available 0.2% exploitation probability (EPSS)

Get an e-mail when this CVE is exploited, patched or re-scored. Free account.

Alert me

AnalysisAIv1 – Oct 24, 2026

Use-after-free and linked-list corruption in the Linux kernel's drm/xe (Intel Xe) GPU driver arise when a buffer object is pinned simultaneously through the external path (xe_bo_pin_external, e.g. dma-buf export) and as a display scanout framebuffer (__xe_pin_fb_vma), and the external unpin occurs before the framebuffer performs the final pin_count 1 -> 0 transition; the bo is then left on xe->pinned.late.external after being freed, so the stale node points into freed memory. Exploitation requires a local, authenticated user (CVSS:3.1/AV:L/AC:L/PR:L/UI:N) able to allocate Xe buffer objects, perform dma-buf export and drive framebuffer pinning, and yields high confidentiality, integrity and availability impact (CVSS 7.8) consistent with kernel memory corruption that could be leveraged toward privilege escalation. There is no confirmed active exploitation (not in CISA KEV) and no public exploit identified at time of analysis; EPSS is low at 0.22% (12th percentile), and vendor patches are available in the referenced stable commits and releases.

RemediationAI

Apply the upstream fix, which moves pinned_link removal into xe_bo_account_unpin(); it is available as stable commits cf238c067eaae1cbfb00738e29219b9568d2313e, b3eaff982839e5c22912d604cd8e7748cece8d63 and 3a11adcfd9a2de74d405bd3e8c4d7a1b328e4684 (https://git.kernel.org/stable/c/3a11adcfd9a2de74d405bd3e8c4d7a1b328e4684) and is shipped in Linux 6.18.57, 7.2.11 and 7.3, so upgrade to the matching fixed stable release for your branch or cherry-pick the commit. The available advisories (NVD https://nvd.nist.gov/vuln/detail/CVE-2026-98999, EUVD EUVD-2026-108793) do not document a workaround, and updating the kernel is the only complete fix identified at time of analysis; note that the defect is confined to systems running the drm/xe driver and requires the dual-pin ordering described, so hosts that do not use Xe graphics hardware or the Xe driver are not exposed to this code path, and limiting which local users can open Xe render/display devices reduces the attack surface but does not remove the bug.

Affected VersionsENISA

Linux patch: 0
Linux 44e694958b95395bd1c41508c88c8ca141bf9bd7 <cf238c067eaae1cbfb00738e29219b9568d2313e
Linux 6.8
Linux 44e694958b95395bd1c41508c88c8ca141bf9bd7 <b3eaff982839e5c22912d604cd8e7748cece8d63
Linux patch: 7.3
Linux 44e694958b95395bd1c41508c88c8ca141bf9bd7 <3a11adcfd9a2de74d405bd3e8c4d7a1b328e4684
Linux patch: 6.18.57
Linux patch: 7.2.11

Affected Packages

euvd linux no fix

Source: OSV (Open Source Vulnerabilities)

Affects your stack

Affects 1 package in euvd

Checking this CVE against your own stacks and servers is part of the Basic plan and up.

Technical ContextAI · show details

The flaw is in the drm/xe buffer-object pin accounting. xe_bo_pin_external() and xe_bo_unpin_external() maintain a bo's membership on the xe->pinned.late.external list based on whether the current call is the outermost pin or the final unpin, but __xe_pin_fb_vma()/__xe_unpin_fb_vma() raise and lower the same pin_count for display scanout without going through those helpers and without any ownership of pinned_link. When a bo is pinned both externally and as an fb and the external unpin runs first, xe_bo_unpin_external() correctly sees pin_count > 1 and leaves the bo linked; the later fb unpin performs the real 1 -> 0 transition but never touches pinned_link, so the node stays linked indefinitely and dangles into freed memory once the bo is released, corrupting the list on the next walk or splice. The backup-object sites in xe_bo_notifier_prepare_pinned()/xe_bo_notifier_unprepare_pinned() bypass the helpers the same way but never add to a pinned list, so they are not affected by this list-corruption issue. The fix relocates pinned_link removal into xe_bo_account_unpin(), which runs on every unpin path (kernel, external, framebuffer, backup object) immediately before the true 1 -> 0 transition, relying on list_del_init() operating only on the node itself so removal is list-agnostic regardless of which list (external or kernel_bo_present) the bo is on, and drops the now-redundant explicit list_del_init() calls in xe_bo_unpin_external() and xe_bo_unpin(). No CWE identifier was supplied in the source data; the impact class is a kernel use-after-free/doubly-linked-list corruption. The exact hardware or configuration preconditions beyond use of the Xe driver are not described in the available sources.

Know when the next one hits your stack

  • Watch products and get an email when something new is published
  • Check this CVE against your own stack and servers
  • Exploit and PoC references, threat intelligence from 22 sources

No credit card · 7-day full trial

Severity by source

Vendor (Linux) PRIMARY 7.8 HIGH
AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
vuln.today AI 7.8 HIGH

Local GPU/display access (AV:L, PR:L); the dual-pin/reverse-unpin trigger is attacker-controllable (AC:L); a kernel use-after-free yields full C:H/I:H/A:H.

3.1 AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
4.0 AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

Primary rating from Vendor (Linux).

CVSS VectorVendor: Linux

Attack Vector
Local
Attack Complexity
Low
Privileges Required
Low
User Interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
High

Lifecycle Timeline

4
CVSS changed
Oct 24, 2026 - 14:22 NVD
7.8 (HIGH)
Patch available
Oct 23, 2026 - 13:17 EUVD
CVE Published
Oct 23, 2026 - 12:20 cve.org
HIGH 7.8
CVE Published
Oct 23, 2026 - 12:20 cve.org
UNKNOWN (no severity yet)

DescriptionCVE.org

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)

Executive ViewAI

Why It Matters

A high-severity flaw (CVE-2026-98999) in the Linux kernel's Intel Xe GPU driver could allow a local, authenticated user to corrupt kernel memory, potentially leading to privilege escalation. Systems using Intel Xe graphics on affected kernels are at risk, and while no active exploitation has been observed, the availability of a patch warrants immediate remediation to prevent potential insider threats or compromised accounts from escalating privileges.

Business Impact: High
Compensating Controls

Apply vendor patch.

Threat Intelligence Overview

EPSS Score
0.2%
Top 88% exploitable
Prevalence
Medium
flaw is in the newer Intel Xe (drm/xe) GPU driver, not all Linux systems
Data Quality
4 sources
Confidence: Medium

How this decision was reached

The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.

SignalValue
Severity HIGH
CISA KEV No
Public POC No
EPSS 0.2%
Patch available Yes
Active threat No
Deciding rule
HIGH severity (CVSS 7.0-8.9)
What every action level means
Emergency Immediate action required. Criteria: CRITICAL + in CISA KEV (actively exploited) without patch, OR CRITICAL + EPSS > 30% without patch, OR CRITICAL + active threat signals without patch.
Act Now Prioritize within 24-48h. Criteria: in KEV with patch available, OR CRITICAL + public POC, OR HIGH + EPSS > 10%, OR CRITICAL + active threat, OR any CRITICAL severity.
This Week Schedule remediation this week. Criteria: HIGH severity (CVSS 7.0-8.9). Patch within normal change window.
This Month Plan within 30 days. Criteria: MEDIUM severity (CVSS 4.0-6.9), lower exploitation probability. Include in regular patch cycle.
Monitor Track and reassess. Criteria: LOW severity (CVSS 0.1-3.9), minimal exploitation risk. No immediate action needed.

SSVC AssessmentENISA

SSVC Decision· derived
Defer
Exploitation· derived
None
System Exposure· derived
Small
Automatable· derived
No
Human Impact
High

Priority Score

39
Low Medium High Critical
KEV: 0
EPSS: 0
CVSS: +39
PoC: 0
Weaponized: 0
Threat intel: 0
Gov advisory: 0

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy