CVE-2026-98999

High

Description

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)

SeverityHigh
CVSS7.8
Exploit probability—
ProductLinux
PublishedOct 23, 2026
First seenOct 23, 2026

How to fix

Update
  • Linux Linux3a11adcfd9a2de74d405bd3e8c4d7a1b328e4684, b3eaff982839e5c22912d604cd8e7748cece8d63, cf238c067eaae1cbfb00738e29219b9568d2313e or later

Affected products

ProductAffected versionsFixed in
Linux Linux44e694958b95395bd1c41508c88c8ca141bf9bd7 ≤ v < 3a11adcfd9a2de74d405bd3e8c4d7a1b328e4684, 44e694958b95395bd1c41508c88c8ca141bf9bd7 ≤ v < b3eaff982839e5c22912d604cd8e7748cece8d63, 44e694958b95395bd1c41508c88c8ca141bf9bd7 ≤ v < cf238c067eaae1cbfb00738e29219b9568d2313e, 6.83a11adcfd9a2de74d405bd3e8c4d7a1b328e4684, b3eaff982839e5c22912d604cd8e7748cece8d63, cf238c067eaae1cbfb00738e29219b9568d2313e

Check your version

Choose the product and enter the version you run to see whether it falls in the affected range.

In the Intelligence 360 plan

Attack Surface Management

See the assets tied to your domains, the technologies they run and known vulnerabilities in one list.