CVE-2026-90091 in Linux
Сводка
по VulDB • 18.09.2026
В ядре Linux была устранена следующая уязвимость:
Bluetooth: L2CAP — исправлена гонка данных (race condition) между l2cap_sock_cleanup_listen() и put_chan().
Для сокетов L2CAP, не владеющих sk->sk_socket, чтение l2cap_pi(sk)->chan может находиться в состоянии гонки с одновременным выполнением l2cap_sock_kill() -> l2cap_sock_put_chan(). Это исключает одновременные вызовы протокольных операций (proto_ops), однако доступ в функции l2cap_sock_cleanup_listen() осуществляется через небезопасное чтение без блокировки.
[Задача 1] [Задача 2 (hdev->workqueue)]
l2cap_sock_release(parent) l2cap_disconn_cfm l2cap_sock_cleanup_listen l2cap_conn_del bt_accept_dequeue l2cap_chan_del lock_sock(sk) l2cap_sock_teardown_cb bt_accept_unlink bt_sk(sk)->parent = NULL release_sock(sk) ----------------> lock_sock(sk) parent = /* NULL */ lock_sock(sk) <--------------------- release_sock(sk) sock_set_flag(sk, SOCK_ZAPPED) l2cap_sock_close_cb l2cap_sock_kill(sk) l2cap_sock_put_chan chan = READ l2cap_pi(sk)->chan l2cap_pi(sk)->chan = NULL l2cap_chan_hold_unless_zero l2cap_put_chan(chan) kref_get_unless_zero(&chan->ref)
Задача 1 может обнаружить значение NULL, что приводит к null-ptr-deref (dereferencированию нулевого указателя).
Исправление гонки данных осуществляется путем добавления вызова lock_sock() в l2cap_sock_kill() для синхронизации с l2cap_sock_cleanup_listen(). Функция hold_unless_zero() здесь не требуется, так как l2cap_pi(sk)->chan владеет ссылкой (reference), если оно не равно NULL.
Уточнены комментарии к коду относительно использования блокировок.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.