GHSA-2XGC-RC56-QQM7
Vulnerability from github – Published: 2026-08-15 15:30 – Updated: 2026-08-19 18:32In the Linux kernel, the following vulnerability has been resolved:
i2c: jz4780: Cache host clock rate at probe to prevent CCF prepare_lock deadlock
Fix a severe AB/BA deadlock between the Common Clock Framework (CCF) and the I2C adapter lock, which triggers when an I2C-controlled clock generator client (like the Si5351) is registered or modified under the CCF.
During an i2c client clock (generator) frequency change, the CCF acquires its global 'prepare_lock' mutex and the driver calls i2c_transfer() to update the client's chip registers, stalling for the adapter's I2C bus lock.
Concurrently, an independent, parallel transfer on the same bus (e.g., a GPIO expander handling LEDs) can hold the I2C adapter lock. Inside this parallel transfer path, jz4780_i2c_set_speed() calls clk_get_rate() on the host controller's input clock to calculate bus timings. This call attempts to acquire the blocked CCF 'prepare_lock', creating a circular dependency that freezes the system.
The jz4780 host controller clock itself is static and never changes at runtime.
However, calling clk_get_rate() inside the active transfer path introduces an unnecessary dependency on the CCF internal locks.
Eliminate this synchronous clk_get_rate() call from the active transfer path by caching the static host peripheral clock rate once - inside the private jz4780_i2c structure during jz4780_i2c_probe(). Update jz4780_i2c_set_speed() to use this cached value, safely decoupling active I2C transactions from the CCF internal locks without any risk of stale timings.
Assisted-by web based Google AI (pinpointing the bug and writing the message).
{
"affected": [],
"aliases": [
"CVE-2026-74463"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-15T13:17:50Z",
"severity": null
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ni2c: jz4780: Cache host clock rate at probe to prevent CCF prepare_lock deadlock\n\nFix a severe AB/BA deadlock between the Common Clock Framework (CCF)\nand the I2C adapter lock, which triggers when an I2C-controlled clock\ngenerator client (like the Si5351) is registered or modified under the CCF.\n\nDuring an i2c client clock (generator) frequency change, the CCF acquires its global\n\u0027prepare_lock\u0027 mutex and the driver calls i2c_transfer() to update the client\u0027s\nchip registers, stalling for the adapter\u0027s I2C bus lock.\n\nConcurrently, an independent, parallel transfer on the same bus (e.g., a GPIO\nexpander handling LEDs) can hold the I2C adapter lock. Inside this parallel\ntransfer path, jz4780_i2c_set_speed() calls clk_get_rate() on the host\ncontroller\u0027s input clock to calculate bus timings. This call attempts to acquire\nthe blocked CCF \u0027prepare_lock\u0027, creating a circular dependency that freezes\nthe system.\n\nThe jz4780 host controller clock itself is static and never changes at runtime.\n\nHowever, calling clk_get_rate() inside the active transfer path introduces\nan unnecessary dependency on the CCF internal locks.\n\nEliminate this synchronous clk_get_rate() call from the active transfer\npath by caching the static host peripheral clock rate once - inside the private\njz4780_i2c structure during jz4780_i2c_probe(). Update jz4780_i2c_set_speed()\nto use this cached value, safely decoupling active I2C transactions from the\nCCF internal locks without any risk of stale timings.\n\nAssisted-by web based Google AI (pinpointing the bug and writing the message).",
"id": "GHSA-2xgc-rc56-qqm7",
"modified": "2026-08-19T18:32:28Z",
"published": "2026-08-15T15:30:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-74463"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/14429dc1c756c35e106f01ff09cadccb82f5531d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/19b783335d62e7a2367436a6e1f1b37da1878360"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/aa1944b52d6492c48bdd17046578aa0d953546e6"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b6cb47e186abba85a3b08aa3023067ab82577286"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cc111696ef420f6bb552b2526530067977f0b406"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d99607c888f26e8a4e9fe9772860cef4aff86bb4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/deffad5bb4f8b4f09e46252f24754ddc9960b244"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f96a719d9f8a797105ec5cacf568ab128e33391f"
}
],
"schema_version": "1.4.0",
"severity": []
}
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.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.