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

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

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

xebopinexternal() and xebounpinexternal() support nested pins, since the underlying ttmbopin()/ttmbounpin() maintain a pincount refcount rather than a boolean. However, the shrinker accounting calls xettmttaccountsubtract() and xettmttaccountadd() are invoked unconditionally on every pinexternal()/unpinexternal() 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 xebopinexternal(). 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 xeshrinkercount(), 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 pinnedlink list maintenance, so accounting is only updated on the outermost pin and the final unpin.

While centralizing this logic into xeboaccountpin()/ xeboaccountunpin(), also close a second, related accounting gap affecting imported dma-bufs. For an imported bo's ttmtt, xe's ttmttpopulate hook (xettmttpopulate()) early-returns without calling xettmttaccountadd(), since TTMTTFLAGEXTERNAL is set without TTMTTFLAGEXTERNALMAPPABLE. However, TTM core's ttmttpopulate() wrapper unconditionally marks the tt as populated on driver-hook success, so ttmttispopulated() still reports true for it. xeboaccountpin()/xeboaccountunpin() trusted ttmttispopulated() 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 xebopinexternal(), and would have become newly reachable via the fb-pin path once this patch routes xepinfbvma() through xebopinaccount() 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 && !EXTERNALMAPPABLE test xettmttpopulate()/xettmttunpopulate() use to decide whether to act, via a new xettmboisimported() 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 (xepinfbvma()/xeunpinfbvma()), which could leave a stale pinnedlink 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 "lastunpin" variable in xebounpinexternal(), restoring the original inline bo->ttm.pincount == 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---