CVE-2017-1000410 in Linux
Сводка
по VulDB • 21.05.2026
В ядре Linux версий 3.3-rc1 и более поздних обнаружена уязвимость, связанная с обработкой входящих команд L2CAP — сообщений ConfigRequest и ConfigResponse. Данная утечка информации является результатом использования неинициализированных переменных в стеке, которые могут быть возвращены злоумышленнику в неинициализированном состоянии. Манипулируя потоками выполнения кода, предшествующими обработке этих конфигурационных сообщений, злоумышленник также может получить некоторый контроль над тем, какие данные будут содержаться в неинициализированных переменных стека. Это позволяет ему обойти защиту KASLR и стек-канарейки (stack canaries), поскольку таким образом могут быть раскрыты как указатели, так и значения стек-канареек. Комбинация данной уязвимости (например) с ранее опубликованной уязвимостью RCE в парсере конфигурации L2CAP (CVE-2017-1000251) может позволить злоумышленнику эксплуатировать RCE против ядер, собранных с указанными выше средствами защиты.
Специфика данной уязвимости заключается в следующем: в функциях `l2cap_parse_conf_rsp` и `l2cap_parse_conf_req` следующая переменная объявляется без инициализации: `struct l2cap_conf_efs efs;`. Кроме того, при разборе входных конфигурационных параметров в обеих этих функциях оператор switch/case для обработки элементов EFS может пропускать вызов `memcpy`, который записывал бы данные в переменную `efs`:
```c ... case L2CAP_CONF_EFS: if (olen == sizeof(efs)) memcpy(&efs, (void *)val, olen); ... ```
Значение `olen` в указанном условии контролируется злоумышленником, и независимо от этого условия в обеих функциях переменная `efs` в конечном итоге добавляется к исходящему конфигурационному запросу, который формируется:
```c l2cap_add_conf_opt(&ptr, L2CAP_CONF_EFS, sizeof(efs), (unsigned long) &efs); ```
Таким образом, отправив конфигурационный запрос или ответ, содержащий элемент `L2CAP_CONF_EFS`, но с длиной элемента, отличной от `sizeof(efs)`, можно избежать вызова `memcpy` для неинициализированной переменной `efs`, и неинициализированная переменная будет возвращена злоумышленнику (16 байт).
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.