Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessGain local access with GPU/display privileges
-
DeliveryPin a buffer object both via dma-buf export and as a scanout framebuffer
-
ExploitRelease the external pin before the framebuffer unpin
-
ExecutionFramebuffer performs final unpin leaving a stale pinned_link node after free
-
ImpactTrigger 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. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – 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
Affected Packages
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
AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
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.
Primary rating from Vendor (Linux).
CVSS VectorVendor: Linux
Lifecycle Timeline
4DescriptionCVE.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
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.
Apply vendor patch.
Threat Intelligence Overview
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.
EUVD-2026-108793
GHSA-7j8x-2fgw-fvx8
NVD
CVE.org
EPSS
Exploit-DB