{"answers":{"affected":"","exploited":"There is no known exploitation of CVE-2026-72154 in the wild and no public exploit code.","fix":"Apply the vendor's patch.","what":"CVE-2026-72154 is a high-severity vulnerability in Linux, published on 15 Aug 2026. It can only be exploited from the same machine or local network, with no action from the victim."},"fix_prompt":"Check this codebase for CVE-2026-72154 and fix it if it is affected.\n\nWhat it is: CVE-2026-72154 is a high-severity vulnerability in Linux, published on 15 Aug 2026. It can only be exploited from the same machine or local network, with no action from the victim.\nExploitation: There is no known exploitation of CVE-2026-72154 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-72154/ (Markdown: https://insights.sbomify.com/CVE-2026-72154/index.md)","id":"CVE-2026-72154","markdown":"https://insights.sbomify.com/CVE-2026-72154/index.md","name":"CVE-2026-72154","record":{"aliases":["BELL-CVE-2026-72154","DEBIAN-CVE-2026-72154","GHSA-w2g7-86j7-x792","UBUNTU-CVE-2026-72154"],"analysis":{"component_type":"kernel","fix_type":"patch","impacts":["code_execution","privilege_escalation"],"network_reachable":"adjacent_or_local","non_default_config":false,"product_category":"Linux kernel","requires_auth":"low_privilege","summary":"A race condition in OpenRISC jump_label SMP syncing allows stale instruction cache entries, potentially leading to code execution or privilege escalation.","user_interaction":"not_required","vuln_class":"race_condition"},"analysis_generated_by":"qwen3.8-flash-next","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\nopenrisc: Fix jump_label smp syncing\n\nThe original commit 8c30b0018f9d (\"openrisc: Add jump label support\")\ncopies from arm64 and does not properly consider how icache invalidation\non remote cores works in OpenRISC.  On OpenRISC remote icaches need to\nbe invalidated otherwise static key's may remain state after updating.\n\nFix SMP cache syncing by:\n\n 1. Properly invalidate remote core icaches on SMP systems by using\n    icache_all_inv.  The old code uses kick_all_cpus_sync() which runs a\n    no-op IPI function call on remote CPU's which does execute a lot of\n    code and flushes many cache lines in the process, but does not flush\n    all and it's not correct on OpenRISC.\n 2. For architectures that do not have WRITETHROUGH caches be sure\n    to flush the dcache after patching.\n\nTo test this I first reproduced the issue using a custom test module\n[0].  The test confirmed that some icache lines maintained stale\nstatic_key code sequences after calling static_branch_enable().  After\nthis patch there are no longer jump_label coherency issues.\n\n[0] https://github.com/stffrdhrn/or1k-utils/tree/master/tests/smp_static_key_test","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":"openrisc: Fix jump_label smp syncing","id":"CVE-2026-72154","indexable":true,"kev":null,"kind":"cve","links":{"ecosystem":null,"product":null,"products":[],"type":"race_condition","year":"2026"},"n_packages":0,"n_references":3,"next":{"headline":"mtd: spi-nor: swp: Improve locking user experience","id":"CVE-2026-72155"},"packages":[],"prev":{"headline":"irqchip/crossbar: Use correct index in crossbar_domain_free()","id":"CVE-2026-72153"},"products":["Linux"],"published":"2026-08-15","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-08-17","vendors":["Linux"]},"summary":"A race condition in OpenRISC jump_label SMP syncing allows stale instruction cache entries, potentially leading to code execution or privilege escalation.","url":"https://insights.sbomify.com/CVE-2026-72154/"}