CVE-2026-99011
WysokieCVSS 7.1Prawdopodobieństwo exploitacji (EPSS)
Niskie ryzykoPercentyl 10 - wyżej niż 10% wszystkich znanych CVE
Streszczenie
W jądrze Linux w obsłudze Bluetooth SCO występował wyścig między ścieżką odbioru danych (sco_recv_scodata) a zwalnianiem struktury sco_conn, co prowadziło do użycia zwolnionej pamięci (use-after-free). Wskaźnik hcon->sco_data był czyszczony bez trzymania hdev->lock, więc ścieżka RX mogła wykonać kref_get_unless_zero() na już zwolnionym obiekcie. Poprawka nadaje wskaźnikowi rzeczywiste odwołanie i serializuje jego czyszczenie pod hdev->lock.
Ocena ryzyka
Podatność może być wykorzystana przez lokalnego atakującego lub przez spreparowane pakiety Bluetooth do wywołania use-after-free w jądrze, co grozi awarią systemu (panic) lub potencjalnie eskalacją uprawnień.
Rekomendacja
Zaktualizuj jądro Linux do wersji zawierającej poprawkę dla CVE-2026-99011 i w razie możliwości ogranicz dostęp do interfejsów Bluetooth do zaufanych urządzeń.
Inne podatności w Linux kernel
Zobacz wszystkie- CVE-2026-43603Średnie
W sterowniku GPU jądra Linux występuje dereferencja wskaźnika NULL, która może doprowadzić do awarii jądra. Skutkiem może być odmowa usługi (DoS) na dotkniętym systemie.
- CVE-2026-99270Wysokie
W jądrze Linux występuje podatność use-after-free (UAF) w funkcji reqsk_timer_handler(). Gdy migracja gniazda TCP nie powiedzie się w inet_ehash_insert(), kod przechodzi do etykiety no_ownership i natychmiast zwalnia nowy reqsk przez __reqsk_free(), nie zatrzymując wcześniej jego timera, co może prowadzić do UAF.
- CVE-2026-99269Wysokie
W jądrze Linux w schedulerze sched_ext zadanie może znajdować się w nie-lokalnej kolejce DSQ, podczas gdy CPU, które je wysłało, wciąż wykonuje ops.dequeue() i nie wyczyściło flagi SCX_OPSS_DISPATCHING. Ścieżki konsumpcji i przenoszenia DSQ nie czekają na zakończenie wysyłki i mogą operować na zadaniu równolegle z dispatcherem. Poprawka dodaje wywołanie scx_wait_dispatching() przed operacjami na zadaniu.
- CVE-2026-99268Nieznane
W io_uring z IORING_SETUP_DEFER_TASKRUN ukończenia są kolejkowane jako lokalna praca i stają się CQE dopiero, gdy zgłaszający wejdzie do jądra, aby czekać na zdarzenia. io_uring_poll() zgłasza EPOLLIN, jeśli lokalna praca jest oczekująca, ale tylko jeśli praca istnieje w momencie wywołania; po dodaniu DEFER_TASKRUN budzenie ->poll_wq zostało zastąpione bezpośrednim budzeniem zgłaszającego, przez co poll() może zasnąć mimo pojawienia się pracy. Poprawka budzi ->poll_wq, gdy pierwszy wpis trafia na listę pracy, używając w razie potrzeby callbacku RCU.
- CVE-2026-99267Nieznane
W io_uring NAPI przy dynamicznym śledzeniu identyfikator NAPI, który nie był widziany przez minutę, powinien zostać usunięty z listy odpytywanej przez ring. Limit czasu jest jednak liczony niepoprawnie — użyto SEC_CONVERSION zamiast liczby jiffies w sekundzie, co dla HZ=1000 daje około ośmiu lat, a na 32-bitowych systemach powoduje przepełnienie. W rezultacie wpisy nigdy nie są usuwane i każde odpytywanie sprawdza wszystkie historyczne identyfikatory.
- CVE-2026-99266Nieznane
W io_uring zcrx funkcja io_zcrx_queue_cqe() oblicza przesunięcie bufora w obszarze na podstawie net_iov_idx(), które jest typu unsigned int, więc przesunięcie jest wykonywane w 32 bitach, a dopiero wynik jest rozszerzany do u64 w CQE. Obszar może mieć do 1 TB, więc dla każdego niov powyżej pierwszych 4 GB CQE wskazuje aplikacji bufor o 4 GB (lub wielokrotność) poniżej właściwego. Aplikacja czyta złe dane i zwraca bufor, którego nie posiada, przez kolejkę uzupełnień, podczas gdy prawdziwy nigdy nie jest zwracany.
- CVE-2026-99265Nieznane
W io_uring/openclose funkcja io_pipe_fixed() instaluje oba końce potoku w tabeli stałych plików, zwalnia ->uring_lock i kopiuje numery slotów do aplikacji. Jeśli kopiowanie spowoduje błąd, ponownie bierze blokadę i usuwa to, co znajduje się w tych slotach. Gdy żądanie jest wykonywane przez io-wq, blokada jest naprawdę zwalniana, a sloty są widoczne dla innych; zanim ścieżka błędu do nich dotrze, mogą zostać zamknięte i ponownie użyte (przez IORING_OP_CLOSE, bezpośrednie open/accept lub IORING_REGISTER_FILES_UPDATE), co powoduje usunięcie pliku niezwiązanego z nieudanym żądaniem. Poprawka wykonuje kopiowanie z trzymaną blokadą.
- CVE-2026-99264Wysokie
W jądrze Linux naprawiono błąd w io_uring/net dotyczący ponawiania odbioru (recv) na niezatwierdzonych buforach. Gdy odbiór był ponawiany po częściowym transferze, jądro mogło ponownie udostępnić pamięć bufora, do której ponawiane żądanie wciąż zapisywało, co prowadziło do nadpisania danych. Zamiast ponawiać, żądanie jest teraz kończone z otrzymaną liczbą bajtów, a MSG_WAITALL nie jest już respektowane dla buforów inkrementalnych i wiązek wielu buforów.
- CVE-2026-99263Nieznane
W io_uring/poll jeśli wybudzenie ustawi IO_POLL_RETRY_FLAG pomiędzy momentem, gdy zadanie będące właścicielem skonsumuje istniejącą instancję IO_POLL_RETRY_FLAG, a sprawdzeniem pętli w io_poll_check_events(), przetwarzanie żądania zostaje wstrzymane do czasu nadejścia niezwiązanego wybudzenia. Poprawka używa atomic_cmpxchg zamiast atomic_sub_return, aby zagwarantować, że licznik v i poll_refs wynoszą 0 i żadne wybudzenia nie zostaną pominięte.
- CVE-2026-99262Nieznane
W io_uring/timeout żądanie IORING_OP_TIMEOUT uruchamiane przez io-wq z powodu IOSQE_ASYNC ma ten sam problem co poll, futex i waitid. io_wq_submit_work() sprawdza IO_WQ_WORK_CANCEL tylko raz, przed wydaniem żądania; anulowanie w międzyczasie ustawia flagę, otrzymuje -EALREADY i bezskutecznie szuka w ->timeout_list, podczas gdy worker dodaje żądanie i uruchamia timer. Nikt nie sprawdza flagi ponownie i limit czasu trwa do końca, a przy wyjściu z ringu zadanie może zawiesić się na cały czas trwania limitu. Poprawka sprawdza flagę pod ->timeout_lock i odrzuca żądanie, jeśli jest ustawiona.
Oryginalny opis (angielski, źródło NVD)
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: SCO: serialise sco_conn lifetime against sco_recv_scodata() sco_recv_scodata() upgrades the weak hcon->sco_data back-pointer to a strong reference under hdev->lock: hci_dev_lock(hdev); hcon = hci_conn_hash_lookup_handle(hdev, handle); ... conn = sco_conn_hold_unless_zero(hcon->sco_data); hci_dev_unlock(hdev); but the pointer is cleared from the other side without that lock. When the last sco_conn reference is dropped, sco_conn_free() ran conn->hcon->sco_data = NULL; with no hdev->lock held, so the RX path could read hcon->sco_data and call kref_get_unless_zero() on an sco_conn that was concurrently freed: BUG: KASAN: slab-use-after-free in sco_conn_hold_unless_zero+0xbe/0x160 Write of size 4 by task kworker/u17:0 Workqueue: hci0 hci_rx_work Call Trace: sco_conn_hold_unless_zero+0xbe/0x160 sco_recv_scodata+0x13f/0x490 hci_rx_work+0x3af/0x730 kref_get_unless_zero() only guards against a zero refcount, not against the backing memory already being freed. Give hcon->sco_data an actual reference on the sco_conn it points to, so the object cannot be freed while the pointer is still installed, and only clear and drop it from sco_conn_del(), which runs under hdev->lock (its callers, sco_connect_cfm() and sco_disconn_cfm(), hold it). The reader in sco_recv_scodata() also takes hdev->lock, so the store and the read are now serialised: the RX path either observes NULL or a reference that is guaranteed to stay valid until it drops its own. sco_conn_add() no longer hands its kref_init() reference to the caller as the connection's only reference; that initial reference is the one owned by hcon->sco_data, and callers get their own via sco_conn_hold(). Because the sco_conn can now outlive the socket (the association keeps it alive until the link goes down), the hci_conn can no longer be dropped from sco_conn_free() without regressing socket close: closing a connected SCO socket must still tear the link down. Move hci_conn ownership to the socket instead: __sco_chan_add() takes an hci_conn reference and it is released from sco_chan_del() and sco_sock_destruct(), exactly once. The sco_conn no longer owns an hci_conn reference, so sco_conn_add() stops consuming one and sco_connect() drops the hci_connect_sco() reference on every path; sco_connect_cfm() no longer needs its hci_conn_hold() dance.
Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS