Goal Reached Thanks to every supporter — we hit 100%!

Goal: 1000 CNY · Raised: 1359 CNY

100%

CVE-2026-99000— drm/xe: Fix shrinker accounting double-subtraction on nested external pins

Quick assessment

Affected
Linux Linux
Exploitation
No confirmed in-the-wild exploitation; assess based on exposure
Recommended action
Check the vendor advisory and references for a fixed version. If immediate upgrade is impossible, restrict exposure and increase monitoring.

在 Linux 内核中,以下漏洞已得到修复: drm/xe:修复嵌套外部钉住(pin)操作导致的收缩器(shrinker)记账重复扣除问题 和 支持嵌套钉住操作,因为底层的 / 维护的是一个 引用计数,而非布尔值。然而,收缩器记账函数 和 却在每次调用 / 时无条件执行,而不是仅在对象从“未钉住”状态过渡到“钉住”状态,或从“钉住”状态过渡回“未钉住”状态时才执行。 一个外部缓冲区对象(BO,即 dma-buf)在已经处于钉住状态时,可能被多次钉住。例如,当该对象拥有多个附着点(attachments)或导入者(i

AI Predicted 5.5 Difficulty: Hard EPSS 0.18% · P7

Possible ATT&CK Techniques 2 AI

T1562.001 T1562.007

Affected Version Matrix 8

VendorProduct Version RangeStatus
Linux Linux 00c8efc3180f0cf919b53980e969430657e01685< 993c952e6832ad0aa4be82e11f0760b1f532090a affected
00c8efc3180f0cf919b53980e969430657e01685< ab39bc55cf08208b8511b1c09926b1b646a8befc affected
00c8efc3180f0cf919b53980e969430657e01685< 83d5acca1f4f6132038ea88c72c5844f62e42d44 affected
6.15 affected
< 6.15 unaffected
6.18.57≤ 6.18.* unaffected
7.2.11≤ 7.2.* unaffected
7.3≤ * unaffected
Get alerts for future matching vulnerabilities Log in to subscribe

I. Basic Information for CVE-2026-99000

Vulnerability Information

Have questions about the vulnerability? See if Shenlong's analysis helps!
View Shenlong Deep Dive ↗

Although we use advanced large model technology, its output may still contain inaccurate or outdated information.Shenlong tries to ensure data accuracy, but please verify and judge based on the actual situation.

Vulnerability Title
drm/xe: Fix shrinker accounting double-subtraction on nested external pins
Source: CVE Program / CVE List V5
Vulnerability 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---
Source: CVE Program / CVE List V5
CVSS Information
N/A
Source: CVE Program / CVE List V5
Vulnerability Type
N/A
Source: CVE Program / CVE List V5

Affected Products

Vendor Product Affected Versions CPE Subscribe
Linux Linux 00c8efc3180f0cf919b53980e969430657e01685 ~ 993c952e6832ad0aa4be82e11f0760b1f532090a -
Linux Linux 6.15 -

II. Public POCs for CVE-2026-99000

# POC Description Source Link Shenlong Link
AI-Generated POC Premium

No public POC found.

Login to generate AI POC

III. Intelligence Information for CVE-2026-99000

请登录查看更多情报信息。

Patches & Fixes for CVE-2026-99000 (3)

Same Patch Batch · Linux · 2026-10-23 · 217 CVEs total

CVE-2026-98959 9.8 CRITICAL btrfs: fix xattr replace when multiple xattrs are packed in the same item
CVE-2026-99078 9.8 CRITICAL net/mlx5e: Prevent stale XSK buffer release on MPWQE refill retry
CVE-2026-99079 9.8 CRITICAL net/mlx5e: Prevent stale XSK buffer release on refill retry
CVE-2026-98988 8.8 HIGH namespace: keep covered mounts covered in OPEN_TREE_NAMESPACE
CVE-2026-99083 8.8 HIGH ksmbd: fix heap out-of-bounds write in krb5_authenticate()
CVE-2026-99082 8.8 HIGH KVM: x86: Use active memslots for the per-vCPU MMIO cache
CVE-2026-98870 8.8 HIGH ksmbd: remove stale channels from all sessions on teardown
CVE-2026-98980 8.8 HIGH namei: don't reveal overmounted entries in refwalk
CVE-2026-98981 8.8 HIGH namespace: unhash a dentry before detaching the mounts on it
CVE-2026-99042 8.4 HIGH io_uring/net: populate CONNECT filter fields for 24-byte sockaddr_in6
CVE-2026-98978 8.4 HIGH namespace: never expire a locked mount
CVE-2026-99064 8.1 HIGH cipso: adjust cached option offsets when removing CIPSO
CVE-2026-98968 8.1 HIGH amt: send the relay's General Query directly from the receive path
CVE-2026-98993 7.8 HIGH namespace: don't inherit MNT_UMOUNT in clone_mnt()
CVE-2026-99053 7.8 HIGH tipc: hold a reference to nodes found by link name
CVE-2026-99054 7.8 HIGH tipc: destroy topsrv workqueues before closing connections
CVE-2026-99056 7.8 HIGH strparser: make sure __strp_recv isn't running before tearing down the parser
CVE-2026-99002 7.8 HIGH drm/vmwgfx: validate pitch coming from userspace
CVE-2026-98899 7.8 HIGH netfilter: ipset: mark the rcu locked areas properly
CVE-2026-99006 7.8 HIGH drm/i915/gem: Prevent overstepping exec array boundary

Showing top 20 of 217 CVEs. View all on vendor page &rarr; →

IV. Related Vulnerabilities