CVE-2026-98999
HighCVSS 7.8Exploitation Probability (EPSS)
Low risk12th percentile - higher than 12% of all known CVEs
Summary
In the Linux kernel's drm/xe subsystem, a stale pinned_link entry is left when framebuffer pinning performs the final unpin. This leaves a list entry pointing into freed memory, risking list corruption and a use-after-free on subsequent list walks or splices.
Risk Assessment
This can cause kernel list corruption and use-after-free, leading to system instability or potential privilege escalation.
Recommendation
Update the Linux kernel to a version containing the fix (commit ca58d36a1f93af586ee93b340c9f9fd81312cc01) and deploy it on systems using the drm/xe driver.
Other vulnerabilities in Linux kernel drm/xe
See all- CVE-2026-98919Unknown
In the Linux kernel, a vulnerability was fixed in the drm/xe component's adjust_idledly() function, which failed to handle corner cases. When xe_gt_clock_init() fails to recognize the crystal clock, timestamp_base is 0, leading to a divide-by-zero and kernel panic. Additionally, u32 tick-to-ns conversions can overflow, and incorrect rounding can program a delay value greater than or equal to maxcnt, triggering warnings on every initialization.
- CVE-2025-68802Unknown
A vulnerability was found in the Linux kernel drm/xe component where the exec and vm_bind ioctls do not bound the num_syncs value. Userspace can specify an arbitrarily large num_syncs, forcing an excessively large allocation and triggering kernel page allocator warnings. The fix introduces DRM_XE_MAX_SYNCS (1024) and rejects requests exceeding this limit.
- CVE-2026-98310Low risk· EPSS 5%
In the Linux kernel's drm/xe/shrinker component, a bug was found where __xe_shrinker_walk() walks the SYSTEM and TT LRUs without a runtime PM reference. Shrinking a buffer object outside system memory invalidates its GPU mappings, which requires the device to be resumed — while runtime suspended this trips an assertion warning and the TLB invalidation returns -ENODEV.
- CVE-2026-97620Low risk· EPSS 9%
In the Linux kernel, the drm/xe driver's emit_render_cache_flush() did not request a flush of the LSC untyped L1 dataport cache before releasing memory for reuse. Starting with MTL, the coupling between HDC Pipeline Flush and the untyped L1 cache flush no longer holds reliably, potentially allowing stale data to leak. The fix explicitly sets PIPE_CONTROL0_UNTYPED_DATAPORT_CACHE_FLUSH on Xe2 and later platforms.
- CVE-2026-90047High
A bug in the Linux kernel's drm/xe component caused get_flat_ccs_offset() to round the end of usable VRAM upwards, exposing memory belonging to the hardware compression (flat CCS) region to the VRAM allocator as free memory. The compression hardware then overwrote data in that area without the driver's knowledge, corrupting page tables and hanging the compositor (black screen). The issue primarily affects Intel Battlemage G21 hardware.
Original NVD description (English source)
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)
Vulnerability data from NVD (NIST) · CISA KEV · EPSS