CVE-2026-89725
nicheOut-of-bounds kernel write in Linux STM32 CEC driver via overlong CEC frames
The Linux kernel's STM32 CEC driver (drivers/media/cec/platform/stm32) stores every received CEC byte into a fixed 16-byte array using rx_msg.len as an incrementing index, without checking it against CEC_MAX_MSG_SIZE before the write. A malicious device attached to the same HDMI-CEC bus can transmit bytes without asserting end-of-message, repeatedly firing the receive-byte interrupt and pushing peer-controlled data out of bounds into adjacent kernel memory from the IRQ thread, with no local privilege needed on the target. Successful exploitation can corrupt kernel memory, causing crashes or potential kernel-level code execution, and the CEC core's own length check runs too late to prevent it. Only systems running Linux on STM32 SoCs with this driver probed and CEC reception enabled are affected. The flaw was found by static analysis (CodeQL), has no public proof-of-concept, and is not in CISA's KEV, so exploitation is not known to have occurred.
What to do: Apply a kernel containing the upstream fix, which bounds rx_msg.len in stm32_rx_done() before the store, and backport it if you ship an STM32-based embedded product. If CEC receive functionality is not needed, disable the stm32 CEC driver or its device-tree node. Operators should treat any device sharing an HDMI-CEC bus with untrusted peers as potentially exposed and watch for kernel oopses or memory-corruption symptoms.
| Linux (upstream kernel; STMicroelectronics stm32 platform driver) Linux kernel — drivers/media/cec/platform/stm32 (STM32 CEC driver) | — |
Order-of-magnitude estimate by the model from install counts, market share and public scan data it knows; verify before quoting.
In the Linux kernel, the following vulnerability has been resolved: media: cec: stm32: prevent out-of-bounds write on RX overflow stm32_rx_done() appends each received CEC byte to rx_msg.msg[] using rx_msg.len as the write index, incrementing it on every RXBR (receive-byte-ready) interrupt without checking it against the buffer size: cec->rx_msg.msg[cec->rx_msg.len++] = val & 0xFF; rx_msg.msg[] is a fixed CEC_MAX_MSG_SIZE (16) byte array in struct cec_msg, and rx_msg.len is only reset on RXACKE/RXOVR or after a completed message (RXEND). The number of bytes received before RXEND is decided by the remote CEC device (it sets EOM), not by the driver. A peer that keeps sending bytes without ending the message drives RXBR repeatedly, pushing rx_msg.len past 16 and writing peer-controlled bytes out of bounds into the surrounding memory. This is reachable in normal operation once the driver has probed and receiving is enabled, from the IRQ thread, without any local privilege. The length check in the CEC core runs on the consumer side, after the byte has been stored, so it does not prevent the overflow. Bound the index in the driver before the store, as the other platform CEC drivers already do (e.g. tegra_cec), dropping the excess bytes of an overlong frame. Found by static analysis tool CodeQL.
- Vector
- CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
In the news0 stories
No ingested article mentions this CVE yet.