CVE-2026-80953

What it actually does

The Analog Devices I3C master driver requests the IRQ and unmasks REG_IRQ_PENDING_CMDR during probe before the transfer-queue list, IBI state, and xferqueue spinlock are initialized. A pending CMDR interrupt can therefore enter adi_i3c_master_irq() and acquire an uninitialized dynamic lock. That produces undefined kernel behavior: lockdep failures on a non-static key, use of an uninitialized spinlock in interrupt context, possible kernel oops or panic, and in the worst case corruption of kernel synchronization or memory state with high confidentiality, integrity, and availability impact on the local host.

Why it matters to the business

Systems that bind the ADI I3C master controller can fail at boot or device-probe time, taking down I3C peripherals and potentially the whole host. The issue is a local kernel race (CVSS 8.4), not known to be exploited in the wild: it is not in CISA KEV, is not associated with ransomware, has no public exploit maturity, and has a very low, flat EPSS (~0.19% over 30 days). Treat as a high-severity kernel correctness bug with moderate operational urgency—patch on the next kernel cycle, faster for embedded, industrial, or always-on platforms that load this driver early.

How an attack unfolds

An attacker who already has local presence on a machine whose kernel includes the vulnerable ADI I3C master driver waits for or induces probe of that controller while a command-ready interrupt is pending. Probe unmasks the IRQ before the transfer-queue lock and IBI state exist, so the ISR can take the uninitialized lock. The typical outcome is a kernel warning, oops, or panic during driver bind; if the uninitialized lock object happens to be in a usable state, kernel memory or lock state can be corrupted, which in principle could be leveraged for local privilege escalation. No named threat actors or campaigns are associated with this CVE, remote exploitation is not indicated, and there is no evidence of in-the-wild use.

How to fix it

Apply the upstream Linux kernel fix that initializes the transfer queue, IBI state, and associated locks before requesting the IRQ and unmasking REG_IRQ_PENDING_CMDR. Upgrade to a distro or vendor kernel that includes that probe-order change (no specific fixed version was supplied with this record—track your kernel tree, stable backports, and vendor advisories). If the ADI I3C master is not required, do not load or bind that driver (module blacklist / disable in device tree or kernel config) until the patched kernel is deployed. Rebuild and redeploy custom or embedded kernels rather than relying on out-of-tree driver copies.

How to confirm the fix worked

Confirm the running kernel changelog, distro advisory, or git history includes the ADI I3C probe-order fix (lock and IBI init before IRQ request/unmask). After upgrade, bind the driver under lockdep-enabled or debug kernels if available and verify probe completes without lockdep non-static-key warnings or oopses in adi_i3c_master_irq. On production kernels, check dmesg/journal around I3C master probe and confirm I3C transfers and IBIs function. Systems that blacklisted the module should remain stable with the driver unbound.

Typical attack path

1. Gain local presence on a host that can load the Analog Devices I3C master driver.
2. Wait for or trigger adi_i3c_master_probe() (boot, module load, or device bind) while a CMDR interrupt is pending.
3. Have the ISR run after the IRQ is unmasked but before the transfer-queue lock and IBI state are initialized.
4. Cause the handler to acquire the uninitialized xferqueue.lock, producing kernel undefined behavior.
5. Resulting crash, hang, or kernel-memory corruption may be abused for denial of service or, if corruption is controllable, local privilege escalation.

How to detect it

This defect surfaces at driver probe time, not as a distinct network payload. Hunt kernel logs (dmesg, journald/kern.log, serial console, crash dumps, pstore) from boot and module-load windows for lockdep complaints about a non-static key and for oops or warning stacks through adi_i3c_master_irq and adi_i3c_master_probe, typically involving lock_acquire and _raw_spin_lock_irqsave. Correlate with loading of the ADI I3C master module and I3C controller bind. A lockdep warning or oops at that site indicates the race fired (often as an accidental pending IRQ during probe), not necessarily a targeted exploit; there are no known campaign artifacts. Absent those kernel messages, prior exploitation is unlikely to be distinguishable from a normal crash.

• INFO: trying to register non-static key
• you didn't initialize this object before use?
• adi_i3c_master_irq
• adi_i3c_master_probe
• _raw_spin_lock_irqsave
• lock_acquire
• REG_IRQ_PENDING_CMDR
• xferqueue.lock

What your security team should do

• Inventory kernels and images that include the Analog Devices I3C master driver and schedule a kernel update containing the probe-order fix.
• Prioritize embedded, industrial, and boot-critical platforms that bind this controller early; the issue is local and not KEV, so do not treat it as an emergency internet-facing patch.
• If the hardware is unused, blacklist or disable the ADI I3C master module until patched kernels are rolled out.
• Watch vendor stable trees for backports; custom kernels must pick up the init-before-IRQ change, not just bump an unrelated version.
• Add kernel-log alerts for lockdep non-static-key messages and oopses in adi_i3c_master_irq / adi_i3c_master_probe as a stopgap while unpatched hosts remain.
• Reassess after patching: this CVE has negligible EPSS movement and no known exploitation, so do not divert incident-response capacity from actively exploited kernel issues.