CVE-2026-80954

What it actually does

The Linux kernel I3C helper i3c_device_get_supported_xfer_mode() reads the device descriptor (dev->desc) without holding bus->lock. That pointer is only valid while the bus lock is held and can be freed or replaced during concurrent I3C device detach or descriptor updates, producing a kernel use-after-free or invalid dereference. The resulting memory corruption can crash the kernel or, given High CIA impact, enable local privilege escalation. The fix obtains the master controller via the always-valid dev->bus pointer instead of the lock-protected descriptor.

Why it matters to the business

A local low-privilege user or compromised process on a Linux host that uses I3C hardware could crash the system or potentially take kernel-level control, causing outages and enabling further compromise. Practical exposure is limited to kernels with I3C enabled and attached I3C devices (embedded, mobile, and some SoC platforms). Exploitation likelihood is very low: EPSS is about 0.00165 and flat over 30 days, the issue is not in CISA KEV, it is not associated with ransomware, exploit maturity is none, and it has been public for about 20 days. Treat as a standard high-severity local kernel defect, not an emergency internet-facing incident.

How an attack unfolds

An attacker with local low-privilege access on a vulnerable kernel races I3C device lifetime changes (attach, detach, or bus reconfiguration that mutates or frees dev->desc) against another thread calling i3c_device_get_supported_xfer_mode(), which dereferences that descriptor without the bus lock. A winning race yields a kernel use-after-free that can panic the host or, if further abused, corrupt kernel objects for privilege escalation. No public exploit, named threat actor, or known in-the-wild use is associated with this issue.

How to fix it

Install a Linux kernel that includes the I3C fix replacing unlocked dev->desc access with the always-valid dev->bus pointer in i3c_device_get_supported_xfer_mode(), then reboot onto that kernel. Track distribution or vendor kernel security advisories for the mapped package; this advisory does not list exact fixed versions. If a patched kernel is not yet available, restrict local unprivileged logins, unload or blacklist the i3c driver where I3C is unused, and prioritize hosts that actually enumerate I3C devices.

How to confirm the fix worked

Verify the running kernel changelog, vendor CVE mapping, or source shows i3c_device_get_supported_xfer_mode() using dev->bus rather than unlocked dev->desc. After upgrade, reboot and confirm the installed kernel package/version is the patched build (uname -r and package manager metadata). Hosts with CONFIG_I3C disabled, no i3c modules loaded, and no devices under the I3C bus are not practically exposed.

Typical attack path

1. Gain local unprivileged access on a Linux system with I3C support in the running kernel
2. Confirm the unfixed i3c_device_get_supported_xfer_mode() path is present
3. Induce concurrent I3C device or bus lifetime operations while the unlocked getter runs
4. Trigger a use-after-free or invalid dereference of the I3C device descriptor in kernel context
5. Cause a kernel oops/panic or, if memory corruption is successfully abused, elevate to kernel privileges

How to detect it

No public exploit or named campaign exists, so confirmed prior abuse is unlikely. Search kernel logs (dmesg, journald, syslog, kdump/vmcore) for oops, WARN, or panic traces involving i3c, i3c_device_get_supported_xfer_mode, or use-after-free/null-pointer paths in the I3C driver, especially coinciding with local unprivileged activity. Review crash RIP/call stacks in I3C functions. Rapid I3C device add/remove or unusual access under /sys/bus/i3c/ from non-privileged processes may indicate racing. Lack of I3C hardware or an unloaded i3c driver makes exploitation impractical.

What your security team should do

• Inventory Linux hosts with I3C enabled (CONFIG_I3C, loaded i3c modules, or I3C devices present) and patch those first
• Deploy vendor or distribution kernels containing the I3C unlocked-dereference fix and reboot
• Until patched, reduce local unprivileged access and container escape surface on I3C-capable systems
• Do not treat this as a KEV-style emergency: EPSS is ~0.00165 and stable, with no known exploits or ransomware use
• Hunt kernel oops/panic logs for I3C-related traces as a backstop, not as evidence of widespread exploitation