В ядре Linux устранена следующая уязвимость:
Bluetooth: L2CAP: исправлено принятие нескольких L2CAP_ECRED_CONN_REQ.
В настоящее время код пытается принимать запросы независимо от
идентификатор команды, который может привести к пометке нескольких запросов
как ожидающий (FLAG_DEFER_SETUP), что может привести к более чем
L2CAP_ECRED_MAX_CID(5) должен быть выделен в l2cap_ecred_rsp_defer
вызывая переполнение.
В спецификации совершенно ясно указано, что один и тот же идентификатор не должен использоваться на
последующие запросы:
«Внутри каждого канала сигнализации должен использоваться другой идентификатор.
для каждого последующего запроса или указания».
https://www.bluetooth.com/wp-content/uploads/Files/Specification/HTML/Core-62/out/en/host/ological-link-control-and-adaptation-protocol-specification.html#UUID-32a25a06-4aa4-c6c7-77c5-dcfe3682355d
Таким образом, это попытка проверить, есть ли какие-либо ожидающие каналы с
тот же идентификатор и отклоняет, если таковые имеются.
Показать оригинальное описание (EN)
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix accepting multiple L2CAP_ECRED_CONN_REQ Currently the code attempts to accept requests regardless of the command identifier which may cause multiple requests to be marked as pending (FLAG_DEFER_SETUP) which can cause more than L2CAP_ECRED_MAX_CID(5) to be allocated in l2cap_ecred_rsp_defer causing an overflow. The spec is quite clear that the same identifier shall not be used on subsequent requests: 'Within each signaling channel a different Identifier shall be used for each successive request or indication.' https://www.bluetooth.com/wp-content/uploads/Files/Specification/HTML/Core-62/out/en/host/logical-link-control-and-adaptation-protocol-specification.html#UUID-32a25a06-4aa4-c6c7-77c5-dcfe3682355d So this attempts to check if there are any channels pending with the same identifier and rejects if any are found.
Характеристики атаки
Последствия
Строка CVSS v3.1