CVE-2026-89725
High · 8.8CVSS
8.8
EPSS
0.3%
Published
Sep 11, 2026
CISA due date
—
Cloudanix analysis
A flaw in Linux kernel code handling certain HDMI control messages can let a nearby device overwrite memory and take control of the system.
- Exploitation
- Adjacent Network
- Attacker needs
- None
- Complexity
- Low
- Impact
- Full Compromise
- Component
- OS kernel
- Class
- Buffer Overflow
- Remediation
- Upgrade
- Effort
- Medium
- Patch risk
- Low
What it actually does
Out-of-bounds write in the Linux kernel CEC STM32 driver where stm32_rx_done() increments rx_msg.len without bounds checking against the 16-byte CEC_MAX_MSG_SIZE array before storing peer-controlled bytes from RXBR interrupts.
Why it matters to the business
Kernel memory corruption on affected embedded Linux systems can cause crashes, data corruption, or remote code execution with no authentication required, potentially disrupting devices that use CEC over HDMI.
How an attack unfolds
An attacker with network-adjacent access to a CEC bus sends an overlong message by repeatedly transmitting bytes without setting EOM; the driver blindly writes each byte past the buffer end from the IRQ context, allowing controlled memory corruption.
How to fix it
Apply the upstream fix that adds an index bounds check before the store operation in stm32_rx_done(); rebuild and deploy the patched kernel. Monitor for backports to stable branches.
How to confirm the fix worked
Confirm the presence of the length check (rx_msg.len < CEC_MAX_MSG_SIZE) before the assignment in the stm32_cec driver source; test by sending an overlong CEC frame and verifying no memory corruption occurs.
Typical attack path
- Attacker connects to CEC bus or emulates a peer device
- Driver probes and enables RX interrupts
- Attacker transmits repeated RXBR bytes without RXEND or ACK
- rx_msg.len exceeds 16 and writes attacker data into adjacent kernel memory
- Corruption leads to crash, information leak, or code execution
How to detect it
Review kernel logs for oops or panic messages involving cec or stm32_rx_done; inspect for unexpected high-volume CEC RXBR interrupts without corresponding RXEND events.
What your security team should do
- Prioritize patching kernel packages on all STM32-based CEC devices within 30 days
- Disable CEC RX functionality where not required
- Monitor kernel logs for unexpected CEC RX overflow or OOPS in cec-stm32
- Apply defense-in-depth with kernel hardening features such as KASAN in test environments
The record
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.
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|