CVE-2026-80951

What it actually does

The Linux kernel Silvaco (svc) I3C master driver copies In-Band Interrupt (IBI) payloads from the controller RX FIFO into an IBI slot with a loop bounded by hardware FIFO size (SVC_I3C_FIFO_SIZE, up to 31 bytes) rather than the allocated slot size. IBI pool slots are sized to max_payload_len, which a client may set smaller than the FIFO (mctp-i3c requests 1 byte). readsb() then copies RXCOUNT bytes with no remaining-space check, so an oversized IBI writes past slot->data into the IBI pool—an out-of-bounds kernel heap write. Leftover FIFO bytes can also leak into a later transfer.

Why it matters to the business

Practical exposure is limited to embedded, IoT, automotive, and SoC platforms that use I3C with the svc master driver; typical enterprise servers are rarely affected. A successful overflow can panic the kernel (unexpected reboot or hang) or, in a worst case, corrupt kernel heap toward privilege escalation and full device control. Likelihood is currently low: EPSS is about 0.002 and stable, the CVE is not on CISA KEV, ransomware use is not reported, exploit maturity is none, and abuse generally needs a malicious or compromised I3C device on the bus. Urgency is modest except where untrusted I3C peripherals are present.

How an attack unfolds

An attacker who can attach or control an I3C slave on a host running the unpatched svc I3C master causes that device to raise an IBI whose payload exceeds the slot size the master requested. The handler copies up to the full FIFO contents into the undersized slot, overflowing the IBI pool and corrupting adjacent kernel heap. That corruption can crash the host immediately or be steered toward kernel-context code execution. Extra RX FIFO bytes that are not flushed can also poison the next transfer. No named threat actors or in-the-wild campaigns are associated with this issue, and there is no public exploit maturity.

How to fix it

Install the Linux kernel update from your distribution or hardware vendor that includes the i3c svc IBI bounds fix: bound the copy loop by max_payload_len, clamp each read to remaining slot space, and flush leftover RX FIFO bytes. No exact fixed package versions were supplied with this record—track distro/vendor advisories mapping CVE-2026-80951. Until patched, load only trusted I3C devices, disable unused svc I3C master support, and do not attach untrusted I3C peripherals.

How to confirm the fix worked

Confirm running kernels include the svc_i3c_master_handle_ibi change that bounds copies by the requested max_payload_len and flushes leftover FIFO data. Map installed kernel packages to vendor changelogs or CVE-2026-80951. Inventory hosts that load the svc I3C master driver and have I3C hardware. After upgrade, verify IBI handling still functions and that kernel logs show no new I3C-related oopses under normal device traffic. Do not use oversized IBI traffic as a production test.

Typical attack path

1. Obtain physical or supply-chain control of an I3C slave on a system using the Linux svc I3C master driver
2. Wait until a client (for example mctp-i3c) has requested an IBI slot with max_payload_len smaller than the hardware FIFO
3. Raise an In-Band Interrupt whose payload is larger than that allocated slot
4. Trigger the unbounded RX FIFO copy so the kernel writes past the IBI slot into the IBI pool
5. Use the resulting kernel heap corruption to deny service (oops/panic) or attempt further kernel compromise

How to detect it

This issue is a local kernel heap overflow via a hardware I3C device, so there are no reliable network signatures. Hunt for whether it was already triggered by reviewing kernel ring buffers, journald/dmesg, kdump/vmcore, and pstore/ramoops on I3C-capable hosts. Look for oops, panic, KASAN slab-out-of-bounds, or paging faults whose call traces include the svc I3C master IBI path. Unexpected reboots of embedded boards that use I3C, especially around MCTP/I3C traffic, are a weak but relevant signal. A crash from a buggy legitimate device can look identical to a malicious oversized IBI; treat hits as exposure evidence, not proof of an attacker.

• svc_i3c_master_handle_ibi
• svc_i3c_master_request_ibi
• svc-i3c-master
• i3c_generic_ibi_alloc_pool
• KASAN: slab-out-of-bounds
• mctp-i3c

What your security team should do

• Inventory systems with I3C hardware and the Linux svc I3C master driver; deprioritize hosts without that stack
• Patch identified kernels via vendor/distro updates that include the IBI payload bound and FIFO flush
• Until patched, restrict the I3C bus to trusted devices and disable unused I3C master support
• Monitor kernel logs and crash dumps for I3C/svc IBI-related oopses rather than treating this as a fleet-wide emergency given low EPSS, no KEV listing, and no known exploit