CVE-2026-98025

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

net: usb: cx82310_eth: upuść URB po ponownym uruchomieniu 0xffff wartownika, aby zapobiec przepełnieniu sterty częściowych_danych

Wskaźnik długości 0xffff wykrywa ponowne uruchomienie routera i planuje
ponowne włączenie trybu Ethernet, ale potem przechodzi do reszty
korpusu pętli. Następna kontrola to

} else if (len > CX82310_MTU) {

co jest else właśnie dopasowanego if -- nigdy nie uruchamia się
len == 0xffff. Ograniczenie MTU, które zwykle ogranicza
ścieżka zapisu niekompletnego pakietu jest dyskretnie pomijana.

Gdy 0xffff > skb->len zawsze ma wartość true (rx_urb_size wynosi 4096),
gałąź niekompletnego pakietu zapisuje dev->partial_len = skb->len bajtów
do dev->partial_data. częściowe_dane to kmalloc(hard_mtu) =
kmalloc(CX82310_MTU + 2) = 1516 bajtów, ale skb->len po
Wartość ściąganego nagłówka 2-bajtowego może wynosić maksymalnie 4094. Urządzenie wysyłające plik
4096-bajtowy URB zaczynający się od [0xff 0xff], dlatego kopiuje 4094
bajtów dostarczonych przez urządzenie do bufora przydzielonego na 1516 bajtów,
przekracza żądany rozmiar o 2578 bajtów.

Następny URB następnie odczytuje dev->partial_len (4094) z tego samego
Bufor 1516-bajtowy i dev->partial_rem (65535 - 4094 = 61441) z
skb nowego URB ~4 KB, oba znacznie przekroczyły przydziały, i
dostarcza wynik połączenia w postaci „ramki” o rozmiarze 64 KB do sieci
stos.

Wyjdź z rx_fixup po zaplanowaniu ponownego włączenia pracy; the
pozostała część znacznika ponownego uruchomienia URB nie jest znaczącymi danymi pakietowymi.
To przywraca niezmiennik, który częściowy_len < CX82310_MTU + 2 włączony
ścieżkę zapisu, ponieważ każda inna trasa już tam minęła
kontrola MTU.