CVE-2026-80953
nicheUninitialized-lock race in Linux kernel ADI I3C master driver
A race condition exists in the Linux kernel's Analog Devices I3C master controller driver: adi_i3c_master_probe() requests the IRQ and unmasks the REG_IRQ_PENDING_CMDR interrupt before the IBI state, transfer queue list, and transfer queue spinlock are initialized. If a pending CMDR interrupt arrives in that window, adi_i3c_master_irq() takes the not-yet-initialized master->xferqueue.lock, which lockdep flags as registering a non-static key and which can crash or corrupt kernel state during driver probe. Exploitation requires local access on a system whose kernel was built with the vulnerable adi-i3c-master driver, typically embedded boards based on Analog Devices I3C-capable SoCs. The flaw was found by static analysis and confirmed with an internal proof-of-concept, but no public exploit exists and no exploitation in the wild has been reported. The fix initializes the IBI state and transfer queue before requesting and unmasking the IRQ.
What to do: Apply a kernel containing the fix, which initializes the IBI state and transfer queue before requesting and unmasking the IRQ; embedded vendors shipping the adi-i3c-master driver should backport the commit. Check kernel configuration: systems that do not enable the ADI I3C master driver are not affected. Because the attack vector is local (CVSS AV:L), restrict unprivileged local and shell access on affected embedded targets until patched.
| Linux kernel (drivers/i3c/master/adi-i3c-master.c, Analog Devices I3C master controller driver) | All kernels containing the vulnerable probe ordering prior to the fixing commit; no specific version range or fixed version number was provided in the data |
Order-of-magnitude estimate by the model from install counts, market share and public scan data it knows; verify before quoting.
In the Linux kernel, the following vulnerability has been resolved: i3c: master: adi: initialize the lock before enabling interrupts adi_i3c_master_probe() requests the IRQ and unmasks REG_IRQ_PENDING_CMDR before the controller's IBI state, transfer queue list and transfer queue lock are initialized. A pending CMDR interrupt can therefore run adi_i3c_master_irq() and take master->xferqueue.lock before the dynamic lock has been initialized. This issue was found by our static analysis tool and then manually reviewed against the current tree. The grounded PoC kept the probe ordering and the IRQ path adi_i3c_master_probe() -> adi_i3c_master_irq() -> xferqueue.lock, with a pending CMDR interrupt arriving after REG_IRQ_PENDING_CMDR is unmasked. Lockdep reported: INFO: trying to register non-static key. you didn't initialize this object before use? lock_acquire+0xbb/0x290 _raw_spin_lock_irqsave+0x36/0x60 adi_i3c_master_irq+0x32/0x56 [vuln_msv] adi_i3c_master_probe+0x5a/0xf47 [vuln_msv] Initialize the transfer queue and IBI state before requesting and unmasking the IRQ.
- Vector
- CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
In the news0 stories
No ingested article mentions this CVE yet.