From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=100.103.45.18 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1792758805; b=XiKUWXBXls7vmcaYN0FwkYfSqWiQiy4ju/v4tDn+gyFaq3fyZi41JHNF11aaff0pLQcf ooGKCERYXHoTGUG0NXN/zBVlaB3lRxffIoUzl8y7xYcYCGnMA/jXj4yis5t64+pudLyes sWbvSTfGHYGdKR48s1N65UE0UEVMECPMtqcagsUig/n9h1p1GGEVo+AY69+RN5i2UH8PO JGCo+enLBmnf2Ybp0FXVl96XqxQ3SXUyrqkgFb7EJVP3PUNcJh565whrouqNzrb4xIU6l Um1zUCcL9Dju9d3l1jXrbA1qoVCZ6/OWQbQoyv0NJybS5ntmEKPBk7q3KM5ETllDRzw== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1792758805; h=Received:DKIM-Signature:From:To:Cc:Subject:Date:Message-ID:X-Mailer: Reply-To:MIME-Version:Lines:X-Developer-Signature:X-Developer-Key: Content-Transfer-Encoding; bh=h53vi1K0HW6VaMJzhI53msTDoiOu7QAsUrLnbvIGk4E=; b=r/PsLYFMiyIVX9XrIrDFwqwKFQ9taTRQoH/hg7BcW5/o2dH1WFO46L3XhKiorGPqiCBp 1x20KWjnlGSJFUXaxtsn6lx/7T0HJZSj57A/uBkXfR6DUseHOK2HYJ8LDGW7C1BIX1rdp VccJP0X6DJiUnom9xIBzUHVooyIwBWLrRucpbDhzQlDwsaHJEZPlpKGZxdh8em2KurFHI fpIrz07ArcR4kNTsEAYuwbmr2cL4HYA1+c4jAYJWG3vgNdwSGmKBzkHmspfgVn4hDqGrc iUSDeZAxbljgWywr3tK94fM/5zq9LpjwIA2cJovHY6Wb3dteLiZJy7e6Ju4UuEPK9+g== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass header.d=linuxfoundation.org header.i=@linuxfoundation.org header.a=rsa-sha256 header.s=korg header.b=Iv9WGHIQ; arc=none smtp.remote-ip=100.103.45.18 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3C64A606A324 for ; Fri, 23 Oct 2026 12:33:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key, unprotected) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.a=rsa-sha256 header.s=korg header.b=Iv9WGHIQ Received: by smtp.kernel.org (Postfix) with ESMTPSA id 069B31F01825; Fri, 23 Oct 2026 12:33:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linuxfoundation.org; s=korg; t=1792758804; bh=h53vi1K0HW6VaMJzhI53msTDoiOu7QAsUrLnbvIGk4E=; h=From:To:Cc:Subject:Date:Reply-To; b=Iv9WGHIQcHcDPsfbvT7RAoQlUDjvcmnWa23oD0lMpafd5otcW2XR0IutdInPz6KSy OL1F/3M7l+zaU+bebtDc2IleH2ChwgWIhcXe/8lZfAX9QpXbSmBznouA7SUpx7oYGk GYGNdn/NfPkjBbwDjrqnBkbZj1UUAn5wsdNbnS8s= From: Greg Kroah-Hartman To: linux-cve-announce@vger.kernel.org Cc: Greg Kroah-Hartman Subject: CVE-2026-98999: drm/xe: Fix stale pinned_link entry when fb-pin performs the final unpin Date: Fri, 23 Oct 2026 14:20:01 +0200 Message-ID: <2026102317-CVE-2026-98999-e897@gregkh> X-Mailer: git-send-email 2.56.0 Reply-To: , X-Mailing-List: linux-cve-announce@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 X-Developer-Signature: v=1; a=openpgp-sha256; l=4007; i=gregkh@linuxfoundation.org; h=from:subject:message-id; bh=FyiteUmAGqidesAJPL2jwSj93W4qa5mMH9pM6NaoSwo=; b=owGbwMvMwCRo6H6F97bub03G02pJDFm3A45mMxmz+zwRSVvh/2ll2aO/0m3ak7VdJa01lWbMZ 8pQvP65I5aFQZCJQVZMkeXLNp6j+ysOKXoZ2p6GmcPKBDKEgYtTACay1oNhwcVpKx3bBR8uWTWv UK4n6cpK9nUaJgwL5h4U3NPYetYszvvig0lHTldEm7xnAAA= X-Developer-Key: i=gregkh@linuxfoundation.org; a=openpgp; fpr=F4B60CC5BF78C2214A313DCB3147D40DDB2DFB29 Content-Transfer-Encoding: 8bit From: Greg Kroah-Hartman Description =========== 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) The Linux kernel CVE team has assigned CVE-2026-98999 to this issue. Affected and fixed versions =========================== Issue introduced in 6.8 with commit 44e694958b95395bd1c41508c88c8ca141bf9bd7 and fixed in 6.18.57 with commit 3a11adcfd9a2de74d405bd3e8c4d7a1b328e4684 Issue introduced in 6.8 with commit 44e694958b95395bd1c41508c88c8ca141bf9bd7 and fixed in 7.2.11 with commit b3eaff982839e5c22912d604cd8e7748cece8d63 Issue introduced in 6.8 with commit 44e694958b95395bd1c41508c88c8ca141bf9bd7 and fixed in 7.3 with commit cf238c067eaae1cbfb00738e29219b9568d2313e Please see https://www.kernel.org for a full list of currently supported kernel versions by the kernel community. Unaffected versions might change over time as fixes are backported to older supported kernel versions. The official CVE entry at https://cve.org/CVERecord/?id=CVE-2026-98999 will be updated if fixes are backported, please check that for the most up to date information about this issue. Affected files ============== The file(s) affected by this issue are: drivers/gpu/drm/xe/xe_bo.c Mitigation ========== The Linux kernel CVE team recommends that you update to the latest stable kernel version for this, and many other bugfixes. Individual changes are never tested alone, but rather are part of a larger kernel release. Cherry-picking individual commits is not recommended or supported by the Linux kernel community at all. If however, updating to the latest release is impossible, the individual changes to resolve this issue can be found at these commits: https://git.kernel.org/stable/c/3a11adcfd9a2de74d405bd3e8c4d7a1b328e4684 https://git.kernel.org/stable/c/b3eaff982839e5c22912d604cd8e7748cece8d63 https://git.kernel.org/stable/c/cf238c067eaae1cbfb00738e29219b9568d2313e