Look up another CVE · open CVE-2026-72154 in the interactive tracker
CVE-2026-72154
openrisc: Fix jump_label smp syncing
Published 2026-08-15 (2 months ago) by the Linux kernel CNA. Subsystem arch/openrisc. Debian urgency: unimportant.
What to do, per Debian release
Debian's own status for CVE-2026-72154 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | not affected | 6.1.190-1 | Nothing to do. bookworm never shipped the vulnerable code. |
| Debian 13trixie | not affected | 6.12.113-1 | Nothing to do. trixie never shipped the vulnerable code. |
| Debian 14forky | fixed | 7.1.5-1 | Update the kernel and reboot. Fixed in 7.1.5-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.1.5-1 | Update the kernel and reboot. Fixed in 7.1.5-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
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
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
arch/openrisc/kernel/jump_label.c
arch/openrisc/kernel/patching.c
- What this is
- STATIC BRANCH/CALLMAINTAINERS section matched on arch/*/kernel/jump_label.c · Supported
Check it on the machine
grep -w CONFIG_JUMP_LABEL /boot/config-$(uname -r)Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.
Show whether Debian builds this, per release
Debian builds this code. Every release with an answer below compiles the affected file into the kernels it ships. The build rule could not be established for 2 releases, so nothing is claimed about those.
- bookworm, trixie?
- forky, sidy
- ?
- not established - no Makefile entry for the affected file
- y
- built into the kernel image on every flavour - only a patch removes it
Where a release above reads "not established", no build rule for the affected file was found in that release's kernel tree. That is a gap in this lookup, not a finding that the code is absent.
- Build switch
- CONFIG_JUMP_LABEL
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages
Signals
- Published
- 2026-08-15 (2 months ago)source
- CVSS
- 7.8 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.17%, higher than 6.3% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- unimportantsource
- Subsystem
- arch/openrisc
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 6.18 | 6.18.40 | 3fac46068fe4 |
| 6.18 | 7.1.5 | 57740658042d |
| 6.18 | 7.2 | aca063c90245 |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:LAttack vector, local
- The bug is in OpenRISC SMP jump_label icache sync during static_branch patching; jump_label_update() is only reached from local kernel entry points (netlink, sysctl, module load) that toggle static keys, not from remote packet or network service handlers.
- AC:LAttack complexity, low
- Stale remote icache after static_branch_enable/disable was reliably reproduced by the fix author; an attacker who toggles static keys while other CPUs execute guarded code controls both sides and does not depend on uncontrollable timing or memory layout.
- PR:LPrivileges required, low
- Triggering jump_label_update() requires static_branch_enable/disable/inc/dec from paths such as nftables/tc netlink (CAP_NET_ADMIN, obtainable in user namespaces) or sysctl/module operations (CAP_SYS_ADMIN in a user namespace), not init-namespace root.
- UI:NUser interaction, none
- No victim interaction is required; exploitation is driven entirely by the attacker's own syscalls/netlink configuration that toggles static keys on an SMP OpenRISC kernel with CONFIG_JUMP_LABEL.
- S:UScope, unchanged
- The flaw causes incorrect kernel branch execution and state on the same machine; it does not cross a VM, container, or IOMMU security boundary to impact a separate security authority.
- C:HConfidentiality impact, high
- Remote CPUs can keep executing stale jmp/nop static_branch instruction sequences after patching, diverging from intended kernel control flow and running security-sensitive paths that should be disabled, enabling unintended kernel memory disclosure.
- I:HIntegrity impact, high
- The same stale icache coherency failure lets remote cores execute kernel write paths gated by static_branch keys in the wrong state, corrupting kernel integrity and enabling arbitrary kernel modification via unintended code execution.
- A:HAvailability impact, high
- Incorrect cached jump_label branches on sibling SMP cores cause wrong kernel execution that can oops, hang, or panic the system; the fix author confirmed persistent stale static_key sequences after static_branch_enable() on remote CPUs.