{"answers":{"affected":"","exploited":"There is no known exploitation of CVE-2026-98999 in the wild and no public exploit code.","fix":"Upgrade to a fixed version.","what":"CVE-2026-98999 is a high-severity vulnerability in Linux, published on 23 Oct 2026."},"fix_prompt":"Check this codebase for CVE-2026-98999 and fix it if it is affected.\n\nWhat it is: CVE-2026-98999 is a high-severity vulnerability in Linux, published on 23 Oct 2026. \nExploitation: There is no known exploitation of CVE-2026-98999 in the wild and no public exploit code.\n\nAffected product: Linux. No package-level version data is available, so check the vendor advisory linked from the reference page.\n\nTask:\n1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.\n2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.\n3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.\n4. Run the tests and summarise what changed and why.\n5. If nothing in the project is affected, say so and change nothing.\n\nReference: https://insights.sbomify.com/CVE-2026-98999/ (Markdown: https://insights.sbomify.com/CVE-2026-98999/index.md)","id":"CVE-2026-98999","markdown":"https://insights.sbomify.com/CVE-2026-98999/index.md","name":"CVE-2026-98999","record":{"aliases":["BELL-CVE-2026-98999","DEBIAN-CVE-2026-98999","GHSA-7j8x-2fgw-fvx8","UBUNTU-CVE-2026-98999"],"analysis":null,"analysis_generated_by":null,"assigner":"Linux","cpe":[],"cvss":{"score":7.8,"severity":"high","source":"cna","vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","version":"3.1"},"cwes":[],"description":"In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/xe: Fix stale pinned_link entry when fb-pin performs the final unpin\n\nxe_bo_pin_external() and xe_bo_unpin_external() maintain the bo's\npinned_link list membership in xe-\u003epinned.late.external, based on\nwhether the current call is the outermost pin or the final unpin.\nHowever, the same external bo's pin_count can also be raised and\nlowered directly by __xe_pin_fb_vma()/__xe_unpin_fb_vma(), which pin\nthe bo as a display scanout buffer without going through\nxe_bo_pin_external()/xe_bo_unpin_external() at all, and have no\nnotion of, or ownership over, pinned_link.\n\nIf a bo is pinned both externally (e.g. dma-buf export) and as an fb,\nand the external unpin happens first, xe_bo_unpin_external() correctly\nobserves pin_count \u003e 1 and leaves the bo on pinned_link. When the fb\nunpin later performs the true last unpin (pin_count 1 -\u003e 0), it never\ntouches pinned_link, leaving the bo linked on xe-\u003epinned.late.external\nindefinitely. Once the bo is subsequently freed, this stale list entry\npoints into freed memory, corrupting the list and risking a\nuse-after-free the next time the list is walked or spliced.\n\nThe backup object pin/unpin sites in xe_bo_notifier_prepare_pinned()/\nxe_bo_notifier_unprepare_pinned() have the same bypass characteristic,\nthough they never add their bo to a pinned list, so are not affected\nby this particular list-corruption issue.\n\nMove the pinned_link removal into xe_bo_account_unpin(), which already\nruns on every unpin path (kernel, external, framebuffer, backup\nobject) right before the true 1 -\u003e 0 pin_count transition. Since\nlist_del_init() only operates on the node itself, this removal is\nlist-agnostic and safe to perform regardless of which list (external\nor kernel_bo_present) the bo happens to be linked on, or which code\npath is performing the final unpin. Drop the now-redundant explicit\nlist_del_init() calls in xe_bo_unpin_external() and xe_bo_unpin().\n\nv2:\n- New patch\n\nv3:\n- Rebased on changes to previous patch.\n\n(cherry picked from commit ca58d36a1f93af586ee93b340c9f9fd81312cc01)","ecosystems":[],"exploits":{"exploitdb":0,"first_seen":null,"github_poc":0,"max_poc_stars":null,"metasploit":0,"nuclei":0,"refs":[],"tier":"none_known"},"has_fix":true,"headline":"drm/xe: Fix stale pinned_link entry when fb-pin performs the final unpin","id":"CVE-2026-98999","indexable":true,"kev":null,"kind":"cve","links":{"ecosystem":null,"product":null,"products":[],"type":null,"year":"2026"},"n_packages":0,"n_references":3,"next":{"headline":"drm/xe: Fix shrinker accounting double-subtraction on nested external pins","id":"CVE-2026-99000"},"packages":[],"prev":{"headline":"drm/bridge: th1520-dw-hdmi: Fix remove() callback","id":"CVE-2026-98998"},"products":["Linux"],"published":"2026-10-23","related":[],"sources":[{"class":"attribution","licence":"CVE Terms of Use (MITRE)","name":"CVE List","prefix":"CVE"},{"class":"attribution","licence":"FIRST CVSS licence","name":"CVSS (FIRST)"}],"ssvc":{"automatable":null,"exploitation":null,"technical_impact":null},"state":"PUBLISHED","updated":"2026-10-24","vendors":["Linux"]},"summary":null,"url":"https://insights.sbomify.com/CVE-2026-98999/"}