Look up another CVE · open CVE-2026-72454 in the interactive tracker
CVE-2026-72454
i3c: mipi-i3c-hci: Fix race in i3c_hci_addr_to_dev()
Published 2026-08-15 (2 months ago) by the Linux kernel CNA. Subsystem drivers/i3c. Debian urgency: not yet assigned.
Debian does not build this code. The per-release build detail is under "Where it lives" below.
What to do, per Debian release
Debian's own status for CVE-2026-72454 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | vulnerable | 6.1.190-1 | No fix published anywhere yet, neither in Debian nor upstream for the series bookworm tracks. Watch the Debian tracker page for this CVE. Advisories for bookworm have historically landed a median of 23 days after publication. |
| Debian 13trixie | vulnerable | 6.12.113-1 | No fix published anywhere yet, neither in Debian nor upstream for the series trixie tracks. Watch the Debian tracker page for this CVE. Advisories for trixie have historically landed a median of 11 days after publication. |
| Debian 14forky | fixed | 7.1.5-1 | Update the kernel and reboot. Fixed in 7.1.5-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.1.5-1 | Update the kernel and reboot. Fixed in 7.1.5-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
i3c_hci_addr_to_dev() walks bus->devs.i3c, which is protected by bus.lock (rwsem). However, it is invoked from the MIPI I3C HCI IRQ handler, which cannot take bus.lock. This allows concurrent device addition/removal in the I3C core to modify the list while it is being traversed, potentially leading to use-after-free or crashes. Remove the dependency on the bus device list and introduce a dedicated lookup table. Add an ibi_devs[] array indexed by DAT entry, maintained under hci->lock. Update the array when IBIs are enabled or disabled, so that it always reflects the set of devices allowed to generate IBIs. Also update when IBIs are freed, to cover the corner case when an IBI is freed without first being disabled (e.g. oldedev in i3c_master_add_i3c_dev_locked()). Move i3c_hci_addr_to_dev() into core.c, reimplement it using the new array, and add a lockdep assertion to enforce that hci->lock is held by callers. Demote a message in PIO and DMA IBI handling, from an error to a debug message, because there is a race window when the condition can arise normally.
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
drivers/i3c/master/mipi-i3c-hci/core.c
drivers/i3c/master/mipi-i3c-hci/dma.c
drivers/i3c/master/mipi-i3c-hci/hci.h
drivers/i3c/master/mipi-i3c-hci/ibi.h
drivers/i3c/master/mipi-i3c-hci/pio.c
- What this is
- I3C SUBSYSTEMMAINTAINERS section matched on drivers/i3c/ · linux-i3c@lists.infradead.org · Maintained
- Kernel module
- none to look for. The file would have gone into mipi_i3c_hci, and Debian does not compile it into that module, so finding mipi_i3c_hci in lsmod would say nothing about this CVE.
Check it on the machine
grep -wE 'CONFIG_I3C|CONFIG_MIPI_I3C_HCI' /boot/config-$(uname -r)Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.
Show whether Debian builds this, per release
Debian does not build this code. In 4 releases below, every kernel flavour Debian publishes has the switch off, so the vulnerable file is compiled into no kernel binary Debian ships.
- bookworm, trixie, forky, sidn
- n
- not enabled on any flavour - this release does not build the code
- Build switches
- CONFIG_I3C, CONFIG_MIPI_I3C_HCI
- Reads as
- all on means the file is compiled; any one off means it is not.
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages
Signals
- Published
- 2026-08-15 (2 months ago)source
- CVSS
- 7.8 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.17%, higher than 5.8% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- Subsystem
- drivers/i3c
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 5.11 | 6.18.57 | 308d7951ca22 |
| 5.11 | 7.1.5 | 8f851cab401c |
| 5.11 | 7.2 | 650716f23eac |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:LAttack vector, local
- The bug is in the MIPI I3C HCI host driver reached only from on-chip hardware IRQs plus local kernel maintenance paths (sysfs do_daa, system suspend/resume re-DAA); there is no network, Bluetooth, or remote packet path to this code.
- AC:LAttack complexity, low
- The race is between the IRQ handler walking bus->devs.i3c without bus.lock and concurrent device add/remove under bus.lock during DAA; a local attacker can repeatedly trigger DAA or suspend/resume while IBI-enabled sensors generate interrupts, controlling both sides of the race.
- PR:LPrivileges required, low
- Exploitation does not require real root in the init namespace; a normal local user can loop system suspend/resume (common on Intel LPSS I3C HCI laptops) to run i3c_master_do_daa_ext() while IBIs fire, though sysfs do_daa also provides a root-only trigger.
- UI:NUser interaction, none
- No victim interaction is required beyond the attacker's own automated suspend/resume or sysfs activity; IBIs from attached I3C peripherals can occur concurrently without any other user action.
- S:UScope, unchanged
- Impact is confined to kernel memory corruption and privilege escalation within the host kernel boundary; this is not a VM escape, IOMMU bypass, or cross-authority sandbox breakout.
- C:HConfidentiality impact, high
- Concurrent list modification during an unlocked list_for_each_entry walk can return a dangling i3c_dev_desc pointer; subsequent dereferences of dev and master_data constitute a use-after-free that can leak kernel heap contents.
- I:HIntegrity impact, high
- The stale dev pointer is used to access dev_data, ibi_data, and IBI slot pools for further processing, enabling controlled writes into freed heap objects and potential kernel code execution via heap grooming.
- A:HAvailability impact, high
- List corruption or use-after-free during IRQ handling can cause immediate kernel oops or panic; even failed exploitation attempts commonly crash the system because the bug fires in hard interrupt context.