CVE-2026-72154

openrisc: Fix jump_label smp syncing

State
Published
Severity
7.8 High
Published
Aug 15, 2026
Updated
Aug 17, 2026
Reserved
Aug 9, 2026

Read the record on cve.org

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

Scores

CVSSScoreVectorSource
3.17.8 HighCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HLinux

Weaknesses

The record names no weakness.

Affected Products

ProductVersions
LinuxLinux
  • 8c30b0018f9d93391573e091960d257fd9de120a to before 3fac46068fe4cea22ed373432b9173a915e8e60dAffected
  • 8c30b0018f9d93391573e091960d257fd9de120a to before 57740658042daf591c57d6e700d9a304d5972552Affected
  • 8c30b0018f9d93391573e091960d257fd9de120a to before aca063c9024522e4e5b9a9d1927433f6a01785a3Affected
LinuxLinux
  • 6.18Affected
  • before 6.18Not affected
  • 6.18.40 through 6.18.*Not affected
  • 7.1.5 through 7.1.*Not affected
  • 7.2 and laterNot affected

References

Every record here comes from the CVE Program’s CVE List. © 1999–2026 The MITRE Corporation. CVE is a registered trademark of The MITRE Corporation. The records are reproduced under the CVE Program terms of use.