Katalog CVE

CVE-2026-90091

WysokieCVSS 8.0
Opublikowano: Zaktualizowano: Przetłumaczono: NVD NIST

Prawdopodobieństwo exploitacji (EPSS)

Niskie ryzyko
0.35%

Percentyl 29 - wyżej niż 29% wszystkich znanych CVE

Streszczenie

W jądrze Linux występuje wyścig (race condition) w podsystemie Bluetooth L2CAP pomiędzy funkcjami l2cap_sock_cleanup_listen() a l2cap_sock_put_chan(). Niezsynchronizowany odczyt wskaźnika l2cap_pi(sk)->chan może zwrócić wartość NULL, co prowadzi do dereferencji wskaźnika NULL (null-ptr-deref) i awarii jądra. Problem został rozwiązany poprzez zastosowanie blokady lock_sock() w l2cap_sock_kill().

Ocena ryzyka

Podatność może być wykorzystana przez lokalnego atakującego do wywołania awarii jądra (odmowa usługi) lub potencjalnie do eskalacji uprawnień. Dotyczy systemów z aktywnym stosem Bluetooth L2CAP.

Rekomendacja

Zaktualizuj jądro Linux do wersji zawierającej poprawkę dla CVE-2026-90091. Jeśli aktualizacja nie jest możliwa, rozważ wyłączenie Bluetooth lub ograniczenie dostępu do interfejsów Bluetooth.

Inne podatności w Linux kernel

Zobacz wszystkie
Oryginalny opis (angielski, źródło NVD)

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: fix race l2cap_sock_cleanup_listen() vs. put_chan For L2CAP sockets without owning sk->sk_socket, reading l2cap_pi(sk)->chan may race against concurrent l2cap_sock_kill() -> l2cap_sock_put_chan(). This excludes simultaneous proto_ops callbacks, but access in l2cap_sock_cleanup_listen() has unsafe lockless read. [Task 1] [Task 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) Task 1 may observe NULL which causes null-ptr-deref. Fix the race by taking lock_sock() in l2cap_sock_kill() to synchronize with l2cap_sock_cleanup_listen(). hold_unless_zero() is not needed here, l2cap_pi(sk)->chan owns reference if it is non-NULL. Clarify code comments vs. locking.

Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS