Look up another CVE · open CVE-2026-80954 in the interactive tracker
CVE-2026-80954
i3c: Fix unlocked dereference of dev->desc in i3c_device_get_supported_xfer_mode()
Published 2026-09-11 (37 days ago) by the Linux kernel CNA. Subsystem drivers/i3c. Debian urgency: unimportant.
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-80954 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 | not affected | 6.1.190-1 | Nothing to do. bookworm never shipped the vulnerable code. |
| Debian 13trixie | not affected | 6.12.113-1 | Nothing to do. trixie never shipped the vulnerable code. |
| Debian 14forky | fixed | 7.2.6-1 | Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.2.6-1 | Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
i3c_device_get_supported_xfer_mode() uses dev->desc to obtain the master controller. However, dev->desc must not be dereferenced unless bus->lock is held, and this function does not take that lock. The function only needs access to the master controller associated with the device's bus. Use dev->bus instead, which is always valid for the lifetime of the device and does not require dereferencing dev->desc.
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/device.c
drivers/i3c/internals.h
drivers/i3c/master.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 i3c, and Debian does not compile it into that module, so finding i3c in lsmod would say nothing about this CVE.
Check it on the machine
grep -w CONFIG_I3C /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 switch
- CONFIG_I3C
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-09-11 (37 days 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.4% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- unimportantsource
- 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 |
|---|---|---|
| 6.19 | 7.2.4 | 251db58324ea |
| 6.19 | 7.3 | 8bed7f4fa710 |
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 unlocked desc dereference is reached from local IIO sysfs reads of an I3C-backed MMC5633 magnetometer (in_magn_*_raw/in_temp_raw via iio_read_channel_info) and from /dev/iio:deviceN; I3C is an on-board host bus with no network or Bluetooth packet path.
- AC:LAttack complexity, low
- A local attacker can loop those IIO reads while concurrently forcing Dynamic Address Assignment, which replaces and kfree()s i3c_dev_desc (hot-join, MIPI I3C HCI/Renesas resume re-DAA, or sysfs do_daa). The attacker drives the unlocked-read side and can retry until it races with DAA.
- PR:LPrivileges required, low
- IIO channel attributes are created 0444/0644 and iio_read_channel_info performs no capability check, so an unprivileged local user on Android, automotive, or embedded I3C boards can invoke mmc5633_read_raw without init-namespace root.
- UI:NUser interaction, none
- The attacker performs their own sysfs or IIO chardev reads against an already-present I3C device; no separate victim action such as plugging hardware or mounting a filesystem is required.
- S:UScope, unchanged
- The use-after-free corrupts an i3c_dev_desc in the host kernel heap and does not cross a VM, IOMMU, or sandbox boundary.
- C:HConfidentiality impact, high
- Unlocked load of dev->desc races with DAA's i3c_master_free_i3c_dev(), so i3c_dev_get_master() walks a freed descriptor (common.master then this->info.hdr_cap). Reclaiming that object yields a kernel read primitive; UAF is High confidentiality.
- I:HIntegrity impact, high
- A sprayed fake i3c_dev_desc lets the nested pointer walk interpret attacker-controlled heap as kernel objects, enabling further writes and control-flow hijack through the same freed slab; UAF is High integrity.
- A:HAvailability impact, high
- Dereferencing a NULL or freed desc in i3c_dev_get_master() causes a kernel oops or panic even without a full exploit, so availability impact is High.