В ядре Linux устранена следующая уязвимость:
Bluetooth: L2CAP: проверьте длину полезной нагрузки L2CAP_INFO_RSP перед доступом.
l2cap_information_rsp() проверяет, что cmd_len покрывает фиксированную
заголовок l2cap_info_rsp (тип + результат, 4 байта), но затем читает
rsp->data без проверки наличия полезной нагрузки:
- L2CAP_IT_FEAT_MASK вызывает get_unaligned_le32(rsp->data), который читает
4 байта после заголовка (требуется cmd_len >= 8).
- L2CAP_IT_FIXED_CHAN читает rsp->data[0], на 1 байт после заголовка
(требуется cmd_len >= 5). Усеченный L2CAP_INFO_RSP с результатом == L2CAP_IR_SUCCESS запускает
чтение за пределами границ соседних данных skb. Защитите каждый доступ к данным с помощью необходимой проверки длины полезной нагрузки.
Если
полезная нагрузка слишком коротка, пропустите чтение и дайте конечному автомату завершиться
с безопасными настройками по умолчанию (feat_mask и Remote_fixed_chan остаются нулевыми с
kzalloc), поэтому очистка информационного таймера и l2cap_conn_start() все еще выполняются.
и соединение не глохнет.
Показать оригинальное описание (EN)
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Validate L2CAP_INFO_RSP payload length before access l2cap_information_rsp() checks that cmd_len covers the fixed l2cap_info_rsp header (type + result, 4 bytes) but then reads rsp->data without verifying that the payload is present: - L2CAP_IT_FEAT_MASK calls get_unaligned_le32(rsp->data), which reads 4 bytes past the header (needs cmd_len >= 8). - L2CAP_IT_FIXED_CHAN reads rsp->data[0], 1 byte past the header (needs cmd_len >= 5). A truncated L2CAP_INFO_RSP with result == L2CAP_IR_SUCCESS triggers an out-of-bounds read of adjacent skb data. Guard each data access with the required payload length check. If the payload is too short, skip the read and let the state machine complete with safe defaults (feat_mask and remote_fixed_chan remain zero from kzalloc), so the info timer cleanup and l2cap_conn_start() still run and the connection is not stalled.