CVE-2026-98999: drm/xe: Fix stale pinned_link entry when fb-pin performs the final unpin

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

drm/xe: Fix stale pinnedlink entry when fb-pin performs the final unpin

xebopinexternal() and xebounpinexternal() maintain the bo's pinnedlink 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 pincount can also be raised and lowered directly by xepinfbvma()/xeunpinfbvma(), which pin the bo as a display scanout buffer without going through xebopinexternal()/xebounpinexternal() at all, and have no notion of, or ownership over, pinnedlink.

If a bo is pinned both externally (e.g. dma-buf export) and as an fb, and the external unpin happens first, xebounpinexternal() correctly observes pincount > 1 and leaves the bo on pinnedlink. When the fb unpin later performs the true last unpin (pincount 1 -> 0), it never touches pinnedlink, 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 xebonotifierpreparepinned()/ xebonotifierunpreparepinned() 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 pinnedlink removal into xeboaccountunpin(), which already runs on every unpin path (kernel, external, framebuffer, backup object) right before the true 1 -> 0 pincount transition. Since listdelinit() only operates on the node itself, this removal is list-agnostic and safe to perform regardless of which list (external or kernelbopresent) the bo happens to be linked on, or which code path is performing the final unpin. Drop the now-redundant explicit listdelinit() calls in xebounpinexternal() and xebounpin().

v2: - New patch

v3: - Rebased on changes to previous patch.

(cherry picked from commit ca58d36a1f93af586ee93b340c9f9fd81312cc01)