CVE-2026-89725 in Linux
Summary
by MITRE • 09/11/2026
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.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/11/2026
The Linux kernel media subsystem contains a critical out-of-bounds write vulnerability within the STM32 HDMI-CEC driver, specifically in the interrupt handler responsible for processing received CEC data. This flaw arises from an insufficient boundary check when appending incoming bytes to a fixed-size buffer. The function stm32_rx_done is triggered by hardware interrupts indicating that a byte has been received via the RXBR signal. In this routine, the code directly assigns the received value to rx_msg.msg[cec->rx_msg.len] and subsequently increments the length counter without verifying whether the index exceeds the maximum allowed message size defined as CEC_MAX_MSG_SIZE, which is sixteen bytes. This design oversight allows an attacker who can control the remote CEC device connected via HDMI to force a buffer overflow by continuously transmitting data frames that do not set the End of Message flag.
The operational impact of this vulnerability is severe because it permits arbitrary write access to kernel memory from user space or external hardware contexts without requiring local privileges. Since the length counter is only reset upon receiving an acknowledge, an overrun condition, or a completed message signal, a malicious peer device can exploit the timing between interrupts to push the index beyond the allocated sixteen-byte array boundary. This results in writing controlled data into adjacent memory structures within the kernel space, potentially leading to code execution, privilege escalation, or system instability through corruption of critical kernel variables and control flow mechanisms. The vulnerability is reachable during normal operation once the driver has been probed and receiving functionality is enabled, making it a persistent threat for systems utilizing STM32 hardware in CEC-enabled environments.
From a technical classification perspective, this issue aligns with CWE-120, which describes buffer copy without checking size limits, specifically manifesting as a stack or heap-based out-of-bounds write depending on the memory layout of the cec_msg structure and surrounding kernel objects. The attack vector leverages external input to trigger an internal state error that bypasses standard validation checks. Although the CEC core layer performs length verification for consumers after data storage, this check occurs too late in the execution pipeline to prevent the initial out-of-bounds write within the driver itself. Consequently, the integrity of kernel memory is compromised before any higher-level security controls can intervene.
To mitigate this vulnerability, developers must implement explicit bounds checking within the stm32_rx_done function prior to performing the array assignment operation. The index should be validated against CEC_MAX_MSG_SIZE for every incoming byte interrupt. If the buffer is full or would exceed its capacity upon receiving another byte, the driver should discard the excess data and potentially reset the reception state machine to prevent further corruption. This approach mirrors best practices observed in other platform-specific CEC drivers such as tegra_cec, which correctly handle frame length limits by dropping overlong frames rather than attempting to store them. By enforcing strict adherence to protocol-defined message sizes at the driver level, the system ensures that memory safety is maintained regardless of malicious or malformed input from connected peripherals.