CVE-2026-80950

What it actually does

A use-after-free in the Linux kernel Renesas I3C master driver allows the interrupt handler to dereference a struct renesas_i3c_xfer after the timeout path has already dequeued and freed it. The resulting kernel memory corruption can cause panics, KASAN/UAF faults, or, given high impact on confidentiality, integrity, and availability, conversion into arbitrary kernel read/write and local privilege escalation on hosts that load this driver.

Why it matters to the business

Hosts with Renesas I3C hardware (typically embedded, automotive, industrial, or SoC Linux platforms) can suffer unexpected kernel crashes, device unavailability, and potential full host compromise by a low-privileged local user. Exploitation likelihood is currently low: EPSS is about 0.17% and flat over 30 days, exploit maturity is none, and the issue is not in CISA KEV and is not associated with ransomware. Patch urgency is still high for multi-user, untrusted-local, or safety-critical systems because impact is severe if the race is won.

How an attack unfolds

An attacker with local, low-privilege access on a system whose kernel includes the vulnerable Renesas I3C driver causes I3C transfers that hit the completion timeout. The waiting thread then frees the transfer object while a late interrupt still runs the ISR against that object, producing a use-after-free in kernel context. With enough control over timing and kernel heap state, that UAF can be abused to corrupt kernel memory and elevate privileges. No public exploit, named threat actor, or in-the-wild campaign is known.

How to fix it

Apply the upstream Linux kernel fix for the Renesas I3C driver that validates the transfer is still live in the interrupt handler, then clears status flags and disables further interrupts to prevent re-entry after free. Deploy the patched kernel from your distribution or SoC vendor as soon as it is available; rebuild custom kernels from a tree that includes that change. Until patched, restrict local untrusted users, unload or blacklist the Renesas I3C driver on systems that do not need I3C, and avoid exposing I3C to untrusted workloads. No per-package fixed-version list was supplied with this record, so track vendor kernel advisories and stable/LTS backports for this CVE.

How to confirm the fix worked

Confirm the running kernel includes the Renesas I3C ISR validity check (transfer still queued before dereference, plus interrupt disable/status clear on invalid xfer). Verify via package/changelog, kernel commit presence, or vendor advisory mapping rather than version guessing. On live hosts, check whether the Renesas I3C driver is loaded and whether I3C controllers are present; systems without that hardware or module are not exposed. After patching, reboot onto the new kernel and confirm the module/kernel version and that I3C transfers complete or time out without oopses.

Typical attack path

1. Obtain local unprivileged access on a Linux host that loads the Renesas I3C master driver
2. Exercise I3C transfers so the asynchronous xfer path can time out and free the transfer object
3. Win a race so a late interrupt still handles the already-freed transfer in the ISR
4. Trigger kernel use-after-free (crash or memory corruption)
5. If corruption is controlled, escalate to kernel read/write and root-equivalent privileges

How to detect it

Look for evidence of prior exploitation or crash-as-probe in kernel logs rather than unique malware artifacts: dmesg, journalctl -k, pstore/ ramoops, crash dumps, and kdump/vmcore around I3C activity. Hunt for oops, panic, general-protection, paging-request, and KASAN slab-use-after-free reports whose call traces mention the Renesas I3C driver or I3C master IRQ/xfer path, especially following transfer timeouts. Correlate with local process activity that talks to I3C (character devices, I3C sysfs, or vendor tools) and with sudden host reboots. Absence of public exploits and named actors means there are no campaign-specific C2 or file IOCs; treat unexplained I3C-related kernel UAFs on unpatched kernels as suspicious.

• KASAN: slab-use-after-free
• renesas_i3c
• renesas_i3c_xfer
• Unable to handle kernel paging request
• Oops:.*i3c
• Call Trace:.*i3c
• timeout.*i3c
• i3c.*IRQ
• BUG: kernel NULL pointer dereference

What your security team should do

• Inventory Linux hosts for Renesas I3C hardware and a loaded Renesas I3C master driver; treat those as in-scope
• Prioritize kernel updates on multi-user, untrusted-local, embedded, and safety-critical fleets even though EPSS and KEV risk are currently low
• Until patched, reduce local attack surface: limit unprivileged access, disable or blacklist the unused driver, and monitor for I3C-related kernel oopses
• Track distribution/SoC vendor backports; this CVE is about 20 days old with no public exploit, but UAF-to-LPE in kernel is high impact
• Add detection for kernel UAF/oops traces involving the Renesas I3C path and hunt historical logs for prior crashes