media: cec: stm32: prevent out-of-bounds write on RX overflow
- Published
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- Fix
- Fixed in 5.10.270, 5.15.221, 6.1.188, 6.6.157, 6.12.109, and 2 more
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
Summary
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.
Timeline
- CVE published
- Record last updated
Affected versions
- Linux Linux
From d69ae57453c80a2193bcdb3fd762efbec447eecf · fixed in f2499b720ea9b874d58770885c6c2e8445a8c3ef; From d69ae57453c80a2193bcdb3fd762efbec447eecf · fixed in 3df1a4026662121011187247897fe95fd84e8a3a; From d69ae57453c80a2193bcdb3fd762efbec447eecf · fixed in 37ac45f7d6e3a6a5dcf6452a0b7bad9a543e8344; From d69ae57453c80a2193bcdb3fd762efbec447eecf · fixed in 1b4fdefd788db990d1805feb5c7b2388de791ecd; From d69ae57453c80a2193bcdb3fd762efbec447eecf · fixed in c3edd7fb8e3692423a702705509947fc9c30b3d1; From d69ae57453c80a2193bcdb3fd762efbec447eecf · fixed in 0c260d3f97e52978a8c769bb095ac0901333a3ac; From d69ae57453c80a2193bcdb3fd762efbec447eecf · fixed in a85ce3b175615c2e13bc01e8a1b6b6b6910fde57; From d69ae57453c80a2193bcdb3fd762efbec447eecf · fixed in fb9dda38d4b9e90db07ed9a0ee2d35bf85494035
- Linux Linux
4.13
- KernelLinux
From 4.13.0 · fixed in 5.10.270; From 5.11.0 · fixed in 5.15.221; From 5.16.0 · fixed in 6.1.188; From 6.2.0 · fixed in 6.6.157; From 6.7.0 · fixed in 6.12.109; From 6.13.0 · fixed in 6.18.50; From 6.19.0 · fixed in 7.2.4
References 8
git.kernel.org
- stable/c/f2499b720ea9b874d58770885c6c2e8445a8c3ef
- stable/c/3df1a4026662121011187247897fe95fd84e8a3a
- stable/c/37ac45f7d6e3a6a5dcf6452a0b7bad9a543e8344
- stable/c/1b4fdefd788db990d1805feb5c7b2388de791ecd
- stable/c/c3edd7fb8e3692423a702705509947fc9c30b3d1
- stable/c/0c260d3f97e52978a8c769bb095ac0901333a3ac
- stable/c/a85ce3b175615c2e13bc01e8a1b6b6b6910fde57
- stable/c/fb9dda38d4b9e90db07ed9a0ee2d35bf85494035