В ядре Linux устранена следующая уязвимость:
media: cec: stm32: запретить запись за пределами допустимого диапазона при переполнении RX
stm32_rx_done() добавляет каждый полученный байт CEC в rx_msg.msg[], используя
rx_msg.len в качестве индекса записи, увеличивая его при каждом RXBR.
(готовность к получению байтов) прерывание без проверки его на соответствие буферу
размер:
cec->rx_msg.msg[cec->rx_msg.len++] = val & 0xFF;
rx_msg.msg[] — это фиксированный массив байтов CEC_MAX_MSG_SIZE (16) в структуре.
cec_msg и rx_msg.len сбрасываются только при RXACKE/RXOVR или после
завершенное сообщение (RXEND). Число байтов, полученных до RXEND, равно
определяется удаленным устройством CEC (оно устанавливает EOM), а не драйвером. А
одноранговый узел, который продолжает отправлять байты, не завершая передачу сообщения, управляет RXBR
неоднократно, перемещая rx_msg.len за пределы 16 и записывая байты, контролируемые одноранговыми узлами
за пределы окружающей памяти.
Это достижимо в обычном режиме
операции после того, как драйвер проверил и включил прием, из
Поток IRQ без каких-либо локальных привилегий. Проверка длины в ядре CEC выполняется на стороне потребителя после
байт сохранен, поэтому он не предотвращает переполнение. Связал
индекс в драйвере перед сохранением, как и другие драйверы CEC платформы.
уже делаю (например, tegra_cec), удаляя лишние байты слишком длинного
рама.
Обнаружено инструментом статического анализа CodeQL.
Показать оригинальное описание (EN)
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.
Характеристики атаки
Последствия
Строка CVSS v3.1
Уязвимые продукты 4
| Конфигурация | От (включительно) | До (исключительно) |
|---|---|---|
|
Linux Linux_Kernel
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
|
4.13
|
6.12.109
|
|
Linux Linux_Kernel
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
|
4.13
|
6.18.50
|
|
Linux Linux_Kernel
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
|
4.13
|
7.2.4
|
|
Linux Linux_Kernel
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
|
4.13
|
7.3-rc1
|