CVE-2026-80952

What it actually does

In the Linux kernel I3C master driver, i3c_master_unregister_i3c_devs() clears i3cdev->dev->desc before device_unregister() finishes. device_del() then emits a KOBJ_REMOVE uevent and unbinds the driver while a valid descriptor is still required. i3c_device_uevent() and a racing modalias_show() can observe a NULL desc and fall back to an uninitialized on-stack i3c_device_info, leaking kernel stack contents into the generated modalias. Driver .remove() callbacks may also see an unexpected NULL desc, and writing desc after the device is released is a use-after-free. Combined, this is a local memory-safety defect with information disclosure plus potential kernel memory corruption (CVSS 7.8, C/I/A High).

Why it matters to the business

A local user or already-compromised process on a Linux system with I3C support can leak kernel memory and, via the use-after-free, potentially crash the host or escalate privileges. That threatens confidentiality of kernel data, integrity of the running kernel, and availability of servers, embedded/IoT devices, and appliances that expose I3C. The issue is 20 days old, is not in CISA KEV, is not associated with ransomware, has no public exploit, and EPSS is very low and flat (~0.0017). Operational urgency is therefore moderate: patch on the normal kernel cadence, faster where untrusted local users or multi-tenant workloads share I3C-capable kernels.

How an attack unfolds

An attacker who already has a local, low-privilege foothold on a vulnerable kernel triggers I3C device unregistration (hot-unplug, driver unbind, or master teardown) while concurrently reading sysfs/uevent modalias data or racing the unbind path. Because desc is cleared too early, uevent/modalias code copies uninitialized stack into userspace, giving a kernel infoleak useful for KASLR or structure layout. Separately, a use-after-free on desc after the device object is freed can corrupt kernel memory during unbind. There are no named threat actors, no KEV activity, and exploit maturity is None; successful abuse still requires local access and a race around I3C unregister, so mass remote exploitation is not indicated.

How to fix it

Apply vendor or distro Linux kernel updates that contain the I3C master unregister fix (keep desc valid until device_unregister() completes; get_device() before unregister, clear desc only afterwards, put_device() to preserve the release-time invariant that desc is NULL). If a packaged kernel is not yet available, backport the upstream i3c master patch into maintained trees. No specific product or version list was provided; track stable/longterm kernels and OEM BSPs that include this change. Until patched, restrict local untrusted users, avoid unnecessary I3C unbind/hot-remove in production, and disable the I3C master driver where the bus is unused.

How to confirm the fix worked

Confirm the running kernel changelog or source includes the i3c master fix that defers desc clearing until after device_unregister() and uses get_device()/put_device() around unregister. After update, exercise I3C device unregister/unbind and verify KOBJ_REMOVE uevents and sysfs modalias no longer contain uninitialized data, and that no NULL-desc oops occurs in i3c_device_uevent or driver remove. On unpatched systems, inventory CONFIG_I3C / loaded i3c master modules and whether I3C devices are present. Compare installed kernel package against the first distro build that cites this CVE or the corresponding stable commit.

Typical attack path

1. Obtain local unprivileged code execution or a shell on a Linux host whose kernel includes the I3C master driver.
2. Cause I3C devices to unregister (device removal, bus teardown, or driver unbind) while the descriptor is cleared too early.
3. Race uevent generation or sysfs modalias reads against unregister to capture leaked kernel stack via the I3C modalias.
4. Optionally race driver .remove() / desc writes after device free to turn the use-after-free into kernel memory corruption.
5. Use leaked kernel addresses or corrupted kernel state to elevate privileges or disrupt the host.

How to detect it

This defect is a local race/UAF and infoleak with no public exploit, so historical compromise is unlikely but not impossible on I3C-capable hosts. Review kernel logs (dmesg, journald/kern, crash dumps) around I3C unbind or device removal for oops/panic in i3c_device_uevent, modalias_show, or I3C driver .remove(), and for KOBJ_REMOVE uevents whose I3C modalias contains non-printable or garbage bytes (stack leak). Check sysfs I3C device modalias nodes captured in live-response or support bundles. Correlate with local unprivileged processes triggering driver unbind, sysfs reads under i3c, or netlink/uevent listeners at the same time. There are no named APT campaigns or ransomware families to hunt. Absence of I3C hardware/modules makes prior exploitation of this specific bug implausible.

• i3c_device_uevent
• modalias_show
• i3c_master_unregister_i3c_devs
• KOBJ_REMOVE
• i3c-dev
• oops: i3c
• Unable to handle kernel NULL pointer dereference.*i3c
• sysfs.*i3c.*modalias

What your security team should do

• Patch Linux kernels that enable I3C as soon as vendor/stable builds with the unregister-path fix are available; do not wait for KEV given CVSS 7.8 kernel memory safety, but deprioritize relative to actively exploited issues (EPSS ~0.0017, no in-the-wild use).
• Inventory hosts with I3C hardware or the I3C master driver loaded; treat multi-user and embedded fleets as higher priority.
• Until patched, limit local untrusted access and avoid routine I3C driver unbind/device teardown on production systems.
• Watch kernel oops/panic telemetry for i3c uevent/unbind crashes and anomalous I3C modalias content as possible pre-patch exposure.
• Track distro and OEM kernel advisories for exact fixed package versions, which were not listed with this record.