Severity by source
AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Adjacent CEC bus access required (AV:A); no credentials or complexity beyond bus connectivity; kernel OOB write yields full C/I/A impact.
Primary rating from Vendor (Linux).
CVSS VectorVendor: Linux
Lifecycle Timeline
5DescriptionCVE.org
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.
AnalysisAI
Out-of-bounds write in the STM32 CEC driver (media/cec/platform/stm32) allows an adjacent attacker on the same HDMI CEC bus to corrupt kernel memory by sending an overlong CEC frame. The stm32_rx_done() IRQ handler appends each received byte to a fixed 16-byte rx_msg.msg[] buffer using rx_msg.len as an unsanitized write index; a peer device that withholds the EOM signal drives RXBR interrupts indefinitely, writing attacker-controlled bytes past the end of the array into adjacent kernel structures. …
Unlock full vulnerability intelligence
- Risk assessment & exploitation conditions
- Attack chain visualization
- Remediation with exact patch versions
- Threat intelligence from 22 sources
- Personal watchlist & email alerts
Free forever · No credit card required
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata
Vulnerability AssessmentAI
| Exploitation | The following conditions must all be present: (1) The target system runs Linux on an STM32 SoC with the stm32-cec driver loaded and CEC reception enabled - this is non-default for general-purpose Linux but is the default operational state on STM32-based CEC-capable media/HDMI devices. … Additional conditions and limiting factors are described in the full assessment. |
| Risk Assessment | The CVSS 8.8 AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H correctly reflects that no credentials or user interaction are needed on the CEC bus side, and that kernel OOB writes carry potential for full confidentiality/integrity/availability compromise. … Full risk analysis with EPSS, KEV, and SSVC signal comparison available after sign-in. |
| Exploit Scenario | Full exploit scenario with step-by-step reproduction available after sign-in. |
| Remediation | Apply the vendor-released patches for your kernel stable branch: upgrade to Linux 6.12.109, 6.18.50, 7.2.4, or 7.3-rc1. … Detailed patch versions, workarounds, and compensating controls in full report. |
Recommended ActionAI
Within 24 hours, contact device vendors and IT asset management teams to begin identifying all STM32-based media devices with HDMI CEC in your environment using manufacturer advisory product lists. …
Sign in for detailed remediation steps and compensating controls.
Threat intelligence, references, and detailed analysis are available after sign-in.
Same technique Buffer Overflow
View allShare
External POC / Exploit Code
Leaving vuln.today
EUVD-2026-76637
GHSA-946x-47hf-5c7p