CVE-2026-90251

W jądrze Linuksa usunięto następującą lukę:

Bluetooth: MSFT: sprawdź evt_prefix_len pod kątem długości odpowiedzi

read_supported_features() sprawdza tylko, czy odpowiedź obejmuje ustaloną
część struktury msft_rp_read_supported_features, która ma 11 bajtów:

if (skb->len < sizeof(*rp)) {
bt_dev_err(hdev, "Niedopasowanie długości funkcji obsługiwanych przez MSFT");
nie udało się;
}

evt_prefix[] jest elastycznym elementem tablicy, a rp->evt_prefix_len jest
unvalidated u8 wzięte bezpośrednio z tej odpowiedzi, więc

msft->evt_prefix = kmemdup(rp->evt_prefix, rp->evt_prefix_len,
GFP_KERNEL);

kopiuje do 255 bajtów z odpowiedzi, która mogła nie zawierać żadnego z nich.
Kopiowane są dane, których administrator nigdy nie wysłał, i do których jest przyzwyczajony
dopasowuje przychodzące zdarzenia dostawców w funkcji msft_vendor_evt().

To nie jest dostęp poza granicami. Alokacja danych skb zawsze ma miejsce
co najmniej SKB_DATA_ALIGN(sizeof(struct skb_shared_info)) bajtów poza
ładunku, który jest większy niż maksymalnie 255 bajtów, więc odczyt pozostaje
wewnątrz alokacji, a KASAN tego nie raportuje. To wciąż lektura
bajtów, które host nigdy nie otrzymał, a długość jest w pełni kontrolowana
kontroler.

Odrzuć odpowiedź, która jest za krótka dla deklarowanego przedrostka.

Zweryfikowano za pomocą emulowanego kontrolera przez /dev/vhci na jądrze KASAN,
z vhci stworzonym do reklamowania kodu operacji MSFT w sposób btintel, btqca, btmtk
i btrtl robią to bezwarunkowo. Odpowiedź zawierająca dokładnie 11 bajtów deklarujących
evt_prefix_len = 255 osiąga kmemdup i kopiuje 255 bajtów
(„skb->len=11 evt_prefix_len=255”, ze zrzuconym skopiowanym buforem); od
odpowiedź kończy się na stałej części, wszystkie 255 pochodzą spoza końca
odpowiedź. Nie sporządza się żadnego raportu KASAN, zgodnie z oczekiwaniami wynikającymi z alokacji
luz opisany powyżej. W przypadku tej poprawki odpowiedź jest odrzucana
„Niedopasowanie długości prefiksu zdarzenia MSFT” i msft->evt_prefix nie są ustawione.