{"cve":"CVE-2026-74463","nvd":{"published":"2026-08-15T13:17:50.963","modified":"2026-08-19T17:21:03.237","status":"Received","description":"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'prepare_lock' mutex and the driver calls i2c_transfer() to update the client's\nchip registers, stalling for the adapter's 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's input clock to calculate bus timings. This call attempts to acquire\nthe blocked CCF 'prepare_lock', 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).","cvss_v4":null,"cvss_v3":null,"cwes":[],"references":["https://git.kernel.org/stable/c/14429dc1c756c35e106f01ff09cadccb82f5531d","https://git.kernel.org/stable/c/19b783335d62e7a2367436a6e1f1b37da1878360","https://git.kernel.org/stable/c/aa1944b52d6492c48bdd17046578aa0d953546e6","https://git.kernel.org/stable/c/b6cb47e186abba85a3b08aa3023067ab82577286","https://git.kernel.org/stable/c/cc111696ef420f6bb552b2526530067977f0b406"],"products":[],"source":"nvd","synced_at":"2026-10-19T22:49:10.689564601+00:00"},"epss":{"cve":"CVE-2026-74463","score":0.0022,"percentile":0.12513,"date":"2026-11-01"},"kev":null,"osv":[],"attribution":["This product uses the NVD API but is not endorsed or certified by the NVD.","EPSS scores: FIRST Exploit Prediction Scoring System, https://www.first.org/epss","Known exploited vulnerabilities: CISA Known Exploited Vulnerabilities Catalog, https://www.cisa.gov/known-exploited-vulnerabilities-catalog","Package advisories: OSV (https://osv.dev), from the GitHub Advisory Database, PyPA, Go, RustSec and other ecosystem databases, under CC-BY 4.0 or CC0","CVE records: the CVE Program's CVE List (https://www.cve.org), under its terms of use (https://www.cve.org/Legal/TermsOfUse). CVE is a registered trademark of The MITRE Corporation; this product is not affiliated with the CVE Program."]}