CVE-2026-80951: i3c: master: svc: bound IBI payload to the requested max_payload_len
In the Linux kernel, the following vulnerability has been resolved:
i3c: master: svc: bound IBI payload to the requested maxpayloadlen
svci3cmasterhandleibi() reads the IBI payload from the RX FIFO into the IBI slot. The loop is bounded by the hardware FIFO size (SVCI3CFIFOSIZE), not by the slot size.
slot->data points into the IBI pool, which i3cgenericibiallocpool() sizes at maxpayloadlen per slot. svci3cmasterrequestibi() only rejects a maxpayloadlen larger than SVCI3CFIFOSIZE, so a driver can request a smaller one. mctp-i3c requests 1. Each readsb() then copies the controller RXCOUNT bytes (up to 31) with no check against the slot size. A device that sends more bytes than the slot holds writes past slot->data, an out-of-bounds write into the IBI pool.
Bound the loop by dev->ibi->maxpayloadlen and clamp each read to the space left in the slot, the same way dw-i3c does. A device can still send more than the requested payload. Flush the leftover bytes from the RX FIFO so they do not leak into the next transfer.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
In svc I3C master, bound the IBI handling loop by dev->ibi->max_payload_len and reject/limit any request where max_payload_len is larger than SVC_I3C_FIFO_SIZE. Clamp each read from the RX FIFO to the current remaining space in the IBI slot so you do not write past the slot size.
i3c master svc (svc_i3c_master_handle_ibi / svc_i3c_master_request_ibi) max_payload_len bounds (SVC_I3C_FIFO_SIZE) = Reject max_payload_len larger than SVC_I3C_FIFO_SIZE; clamp reads and loop by dev->ibi->max_payload_len - Configuration
After copying the IBI payload into the IBI slot, flush any leftover bytes from the RX FIFO so they do not leak into the next transfer.
i3c master svc RX FIFO handling RX FIFO flush of leftover bytes after reading IBI payload = Flush leftover bytes from RX FIFO
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
Systems using the Linux kernel SVC I3C master driver are exposed when an I3C device can send an in-band interrupt (IBI) payload larger than the payload length requested by its driver. The mctp-i3c driver is specifically noted as requesting a maximum payload length of 1 byte.
What does an attacker or malicious device need to do to trigger the flaw?
A connected I3C device must send an IBI containing more data than the allocated IBI slot can hold. Before the fix, the SVC driver could copy up to the controller RX FIFO limit rather than stopping at the requested maximum payload length, causing an out-of-bounds write into the IBI pool.
How can administrators determine whether their kernel includes the fix?
Check whether the kernel includes any of the referenced stable commits: f296a0d5907bf88314dfda67245f7f69d1552470, 5697d779577e2786ff3348ae9b77020ac0cf0aab, or aac3c5aababc7fb69d5bf5b0cc52d308574e3a8c. The corrected behavior bounds copied IBI data by max_payload_len and flushes excess FIFO bytes.