Description
In the Linux kernel, the following vulnerability has been resolved:

drm/xe: Fix shrinker accounting double-subtraction on nested external pins

xe_bo_pin_external() and xe_bo_unpin_external() support nested pins,
since the underlying ttm_bo_pin()/ttm_bo_unpin() maintain a pin_count
refcount rather than a boolean. However, the shrinker accounting calls
xe_ttm_tt_account_subtract() and xe_ttm_tt_account_add() are invoked
unconditionally on every pin_external()/unpin_external() call, instead
of only on the transition into and out of the pinned state.

An external BO (dma-buf) can be pinned more than once while already
pinned, for example when it has multiple attachments/importers, each
independently calling xe_bo_pin_external(). Each such nested pin
subtracts the BO's pages from the shrinker's accounting again, even
though the BO's pages were already removed from consideration by the
first pin. Symmetrically, each nested unpin adds them back again
before the BO is actually unpinned. This desynchronizes the
shrinker's page and object counts from reality, and since they are
declared as signed long but interpreted as unsigned long in
xe_shrinker_count(), the underflow can turn into an enormous
shrinkable/purgeable page count, causing the shrinker to be invoked
excessively under memory pressure.

Guard the accounting calls with the same pin-count transition checks
already used to guard the pinned_link list maintenance, so accounting
is only updated on the outermost pin and the final unpin.

While centralizing this logic into xe_bo_account_pin()/
xe_bo_account_unpin(), also close a second, related accounting gap
affecting imported dma-bufs. For an imported bo's ttm_tt, xe's
ttm_tt_populate hook (xe_ttm_tt_populate()) early-returns without
calling xe_ttm_tt_account_add(), since TTM_TT_FLAG_EXTERNAL is set
without TTM_TT_FLAG_EXTERNAL_MAPPABLE. However, TTM core's
ttm_tt_populate() wrapper unconditionally marks the tt as populated
on driver-hook success, so ttm_tt_is_populated() still reports true
for it. xe_bo_account_pin()/xe_bo_account_unpin() trusted
ttm_tt_is_populated() as a proxy for "these pages are accounted for
by the shrinker", and would subtract/add pages for such a tt that
were never added in the first place, again underflowing the
shrinker's counts. This is reachable today via xe_bo_pin_external(),
and would have become newly reachable via the fb-pin path once this
patch routes __xe_pin_fb_vma() through xe_bo_pin_account() below, so
fix it here rather than in a later patch, to avoid a commit in this
series that introduces the regression before fixing it. Skip the
accounting for imported bos, using the same EXTERNAL &&
!EXTERNAL_MAPPABLE test xe_ttm_tt_populate()/xe_ttm_tt_unpopulate()
use to decide whether to act, via a new xe_ttm_bo_is_imported()
helper (hoisted up from its only prior use site).

v2:
- Fix the critical issue caught by Sashiko AI review: the pin-count
transition check introduced here was still bypassed by the fb-pin
path (__xe_pin_fb_vma()/__xe_unpin_fb_vma()), which could leave a
stale pinned_link entry and a permanent shrinker accounting leak
when the fb-unpin performed the true last unpin. Addressed in a
separate follow-up patch in this series rather than folded in here,
since it is a distinct bug with its own Fixes: tag.
- Drop the unneeded local "last_unpin" variable in
xe_bo_unpin_external(), restoring the original inline
bo->ttm.pin_count == 1 check; it was a no-op rename not used by any
of the new accounting helpers, and was going to be deleted again by
the follow-up patch anyway.

v3:
- Exclude imported dma-bufs from the pin/unpin shrinker accounting,
fixing another underflow caught by Sashiko AI review.
- Add a short comment on the backup-object pin site noting it's
already populated/accounted at pin time, addressing (as a
false-positive clarification, no code fix needed) a separate
Medium-severity accounting-leak concern also caught by Sashiko AI

---truncated---
Published: 2026-10-23
Score: 5.5 Medium
EPSS: < 1% Very Low
KEV: No
Impact: Resource Exhaustion via Shrinker Underflow
Action: Apply Patch
AI Analysis

Impact

The Linux kernel's DRM xe driver contains a bug where nested external buffer pins incorrectly perform shrinker accounting on every pin and unpin call. Each nested pin subtracts page counts again and each unpin adds them back, leading to underflow of signed counters interpreted as unsigned, inflating shrinker page counts and causing excessive memory shrink operations under pressure. The result is a denial–of–service that can stall or thrash the system as the shrinker is invoked excessively.

Affected Systems

Linux kernel, specifically the DRM xe component. No specific versions are listed, so all kernels containing the drm/xe driver prior to this patch are potentially affected. The issue arises wherever external dma‑buf objects are pinned multiple times through xe_bo_pin_external and unpinned via xe_bo_unpin_external. There is no alternative product name; the affected platform is generic Linux kernel DRM.

Risk and Exploitability

Based on the description, it is inferred that the attack vector is local, requiring the ability to trigger nested external pinning via drivers or applications that use the DRM xe component. The vulnerability does not provide remote code execution but can be exploited by anyone with the ability to trigger nested external pinning, such as local users with access to the device or drivers that perform dma‑buf imports. Because the underflow leads to inflated shrinker counters, an attacker could induce severe memory pressure, causing the kernel to aggressively reclaim memory and potentially halt application activity. The EPSS score is <1% and it is not listed in KEV, suggesting the exploit is rare or new, but the potential impact is significant. The CVSS score of 5.5 indicates moderate severity, reflecting a moderate risk to system availability and stability without privilege escalation.

Generated by OpenCVE AI on October 29, 2026 at 21:18 UTC.

Remediation

No solution or workaround provided in the CVE record.

OpenCVE Recommended Actions

  • Update the system to a kernel version that includes this patch or any newer stable release that fixes the shrinker accounting logic.
  • If a timely patch is unavailable, consider disabling the drm/xe module or preventing external dma‑buf pinning in applications that use this driver.
  • Monitor system memory usage and shrinker activity for indications of excessive reclaim cycles, and trigger additional kernel or application resource limits to mitigate service degradation.

Generated by OpenCVE AI on October 29, 2026 at 21:18 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Thu, 29 Oct 2026 19:30:00 +0000

Type Values Removed Values Added
Weaknesses CWE-369
CWE-400

Thu, 29 Oct 2026 12:15:00 +0000

Type Values Removed Values Added
Weaknesses CWE-191
References
Metrics threat_severity

None

cvssV3_1

{'score': 5.5, 'vector': 'CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H'}

threat_severity

Moderate


Fri, 23 Oct 2026 18:45:00 +0000

Type Values Removed Values Added
First Time appeared Linux linux
Vendors & Products Linux linux

Fri, 23 Oct 2026 15:45:00 +0000

Type Values Removed Values Added
Weaknesses CWE-369
CWE-400

Fri, 23 Oct 2026 12:45:00 +0000

Type Values Removed Values Added
Description In the Linux kernel, the following vulnerability has been resolved: drm/xe: Fix shrinker accounting double-subtraction on nested external pins xe_bo_pin_external() and xe_bo_unpin_external() support nested pins, since the underlying ttm_bo_pin()/ttm_bo_unpin() maintain a pin_count refcount rather than a boolean. However, the shrinker accounting calls xe_ttm_tt_account_subtract() and xe_ttm_tt_account_add() are invoked unconditionally on every pin_external()/unpin_external() call, instead of only on the transition into and out of the pinned state. An external BO (dma-buf) can be pinned more than once while already pinned, for example when it has multiple attachments/importers, each independently calling xe_bo_pin_external(). Each such nested pin subtracts the BO's pages from the shrinker's accounting again, even though the BO's pages were already removed from consideration by the first pin. Symmetrically, each nested unpin adds them back again before the BO is actually unpinned. This desynchronizes the shrinker's page and object counts from reality, and since they are declared as signed long but interpreted as unsigned long in xe_shrinker_count(), the underflow can turn into an enormous shrinkable/purgeable page count, causing the shrinker to be invoked excessively under memory pressure. Guard the accounting calls with the same pin-count transition checks already used to guard the pinned_link list maintenance, so accounting is only updated on the outermost pin and the final unpin. While centralizing this logic into xe_bo_account_pin()/ xe_bo_account_unpin(), also close a second, related accounting gap affecting imported dma-bufs. For an imported bo's ttm_tt, xe's ttm_tt_populate hook (xe_ttm_tt_populate()) early-returns without calling xe_ttm_tt_account_add(), since TTM_TT_FLAG_EXTERNAL is set without TTM_TT_FLAG_EXTERNAL_MAPPABLE. However, TTM core's ttm_tt_populate() wrapper unconditionally marks the tt as populated on driver-hook success, so ttm_tt_is_populated() still reports true for it. xe_bo_account_pin()/xe_bo_account_unpin() trusted ttm_tt_is_populated() as a proxy for "these pages are accounted for by the shrinker", and would subtract/add pages for such a tt that were never added in the first place, again underflowing the shrinker's counts. This is reachable today via xe_bo_pin_external(), and would have become newly reachable via the fb-pin path once this patch routes __xe_pin_fb_vma() through xe_bo_pin_account() below, so fix it here rather than in a later patch, to avoid a commit in this series that introduces the regression before fixing it. Skip the accounting for imported bos, using the same EXTERNAL && !EXTERNAL_MAPPABLE test xe_ttm_tt_populate()/xe_ttm_tt_unpopulate() use to decide whether to act, via a new xe_ttm_bo_is_imported() helper (hoisted up from its only prior use site). v2: - Fix the critical issue caught by Sashiko AI review: the pin-count transition check introduced here was still bypassed by the fb-pin path (__xe_pin_fb_vma()/__xe_unpin_fb_vma()), which could leave a stale pinned_link entry and a permanent shrinker accounting leak when the fb-unpin performed the true last unpin. Addressed in a separate follow-up patch in this series rather than folded in here, since it is a distinct bug with its own Fixes: tag. - Drop the unneeded local "last_unpin" variable in xe_bo_unpin_external(), restoring the original inline bo->ttm.pin_count == 1 check; it was a no-op rename not used by any of the new accounting helpers, and was going to be deleted again by the follow-up patch anyway. v3: - Exclude imported dma-bufs from the pin/unpin shrinker accounting, fixing another underflow caught by Sashiko AI review. - Add a short comment on the backup-object pin site noting it's already populated/accounted at pin time, addressing (as a false-positive clarification, no code fix needed) a separate Medium-severity accounting-leak concern also caught by Sashiko AI ---truncated---
Title drm/xe: Fix shrinker accounting double-subtraction on nested external pins
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-10-23T12:20:20.753Z

Reserved: 2026-09-25T10:25:14.385Z

Link: CVE-2026-99000

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-10-23T13:17:22.297

Modified: 2026-10-23T13:17:22.297

Link: CVE-2026-99000

cve-icon Redhat

Severity : Moderate

Publid Date: 2026-10-23T00:00:00Z

Links: CVE-2026-99000 - Bugzilla

cve-icon OpenCVE Enrichment

Updated: 2026-10-29T21:30:15Z

Weaknesses
  • CWE-191

    Integer Underflow (Wrap or Wraparound)