---
id: CVE-2026-98999
title: 'drm/xe: Fix stale pinned_link entry when fb-pin performs the final unpin'
summary: |-
  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 …
severity: high
cvss: 7.8
cvssVector: 'CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H'
cvssSource: cna
vendor: Linux
product: Linux
affected:
  - >-
    Linux >= 44e694958b95395bd1c41508c88c8ca141bf9bd7 <
    3a11adcfd9a2de74d405bd3e8c4d7a1b328e4684
  - >-
    Linux >= 44e694958b95395bd1c41508c88c8ca141bf9bd7 <
    b3eaff982839e5c22912d604cd8e7748cece8d63
  - >-
    Linux >= 44e694958b95395bd1c41508c88c8ca141bf9bd7 <
    cf238c067eaae1cbfb00738e29219b9568d2313e
  - Linux 6.8
published: '2026-10-23'
updated: '2026-10-24'
sourceUpdated: '2026-10-24T14:09:56.167Z'
source: CVEORG
sourceUrl: 'https://www.cve.org/CVERecord?id=CVE-2026-98999'
references:
  - url: 'https://git.kernel.org/stable/c/3a11adcfd9a2de74d405bd3e8c4d7a1b328e4684'
  - url: 'https://git.kernel.org/stable/c/b3eaff982839e5c22912d604cd8e7748cece8d63'
  - url: 'https://git.kernel.org/stable/c/cf238c067eaae1cbfb00738e29219b9568d2313e'
tags:
  - cve.org
epss: 0.00179
epssPercentile: 0.0739
ingestedAt: '2026-10-23T13:24:55.542Z'
---

## Overview

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)

## Affected

- `Linux >= 44e694958b95395bd1c41508c88c8ca141bf9bd7 < 3a11adcfd9a2de74d405bd3e8c4d7a1b328e4684`
- `Linux >= 44e694958b95395bd1c41508c88c8ca141bf9bd7 < b3eaff982839e5c22912d604cd8e7748cece8d63`
- `Linux >= 44e694958b95395bd1c41508c88c8ca141bf9bd7 < cf238c067eaae1cbfb00738e29219b9568d2313e`
- `Linux 6.8`

## Remediation

Refer to the linked advisories for vendor-supplied fixes and affected version ranges.