# CVE-2026-72154: openrisc: Fix jump_label smp syncing

> A race condition in OpenRISC jump_label SMP syncing allows stale instruction cache entries, potentially leading to code execution or privilege escalation.

- **Severity:** High 7.8 (`CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H`)
- **Exploited in the wild:** Not known
- **Login needed:** Any signed-in user
- **Attackable:** Local or same network only
- **Victim action needed:** Not needed
- **Fix available:** Yes
- **Published:** 15 Aug 2026
- **Updated:** 17 Aug 2026
- **Also known as:** BELL-CVE-2026-72154, DEBIAN-CVE-2026-72154, GHSA-w2g7-86j7-x792, UBUNTU-CVE-2026-72154

## What is CVE-2026-72154?

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.

### Official description

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

openrisc: Fix jump_label smp syncing

The original commit 8c30b0018f9d ("openrisc: Add jump label support")
copies from arm64 and does not properly consider how icache invalidation
on remote cores works in OpenRISC.  On OpenRISC remote icaches need to
be invalidated otherwise static key's may remain state after updating.

Fix SMP cache syncing by:

 1. Properly invalidate remote core icaches on SMP systems by using
    icache_all_inv.  The old code uses kick_all_cpus_sync() which runs a
    no-op IPI function call on remote CPU's which does execute a lot of
    code and flushes many cache lines in the process, but does not flush
    all and it's not correct on OpenRISC.
 2. For architectures that do not have WRITETHROUGH caches be sure
    to flush the dcache after patching.

To test this I first reproduced the issue using a custom test module
[0].  The test confirmed that some icache lines maintained stale
static_key code sequences after calling static_branch_enable().  After
this patch there are no longer jump_label coherency issues.

[0] https://github.com/stffrdhrn/or1k-utils/tree/master/tests/smp_static_key_test

## Which versions are affected by CVE-2026-72154?


## How do I fix CVE-2026-72154?

Apply the vendor's patch.

## Is CVE-2026-72154 being exploited?

There is no known exploitation of CVE-2026-72154 in the wild and no public exploit code.

## Fix prompt for AI coding agents

```text
Check this codebase for CVE-2026-72154 and fix it if it is affected.

What 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.
Exploitation: There is no known exploitation of CVE-2026-72154 in the wild and no public exploit code.

Affected product: Linux. No package-level version data is available, so check the vendor advisory linked from the reference page.

Task:
1. 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.
2. 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.
3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.
4. Run the tests and summarise what changed and why.
5. If nothing in the project is affected, say so and change nothing.

Reference: https://insights.sbomify.com/CVE-2026-72154/ (Markdown: https://insights.sbomify.com/CVE-2026-72154/index.md)
```

## Sources

- CVE record: https://www.cve.org/CVERecord?id=CVE-2026-72154
- NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-72154
- OSV: https://osv.dev/vulnerability/CVE-2026-72154

---
From sbomify Insights: https://insights.sbomify.com/CVE-2026-72154/
Summaries are generated and may contain mistakes; the official description above is the record.