GCVE Workshop - 22 September 2026 (14:00-18:00), Luxembourg Before The Vulnopticon Conference - Registration

GHSA-W2G7-86J7-X792

Vulnerability from github – Published: 2026-08-15 06:32 – Updated: 2026-08-17 06:33
VLAI
Details

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

Severity
7.8 (High)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-72154"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-15T06:21:33Z",
    "severity": "HIGH"
  },
  "details": "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\u0027s 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\u0027s which does execute a lot of\n    code and flushes many cache lines in the process, but does not flush\n    all and it\u0027s 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",
  "id": "GHSA-w2g7-86j7-x792",
  "modified": "2026-08-17T06:33:13Z",
  "published": "2026-08-15T06:32:14Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72154"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/3fac46068fe4cea22ed373432b9173a915e8e60d"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/57740658042daf591c57d6e700d9a304d5972552"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/aca063c9024522e4e5b9a9d1927433f6a01785a3"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.





Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.


Detection rules are retrieved from Rulezet.