CVE-2026-98302
>_ Opis
Tłumaczenie automatyczne – może zawierać nieścisłości.
W jądrze Linuksa usunięto następującą lukę:
net: fddi: skfp: napraw deref NULL podczas ustawiania adresu MAC w trybie wyłączonym
skfp_ctl_set_mac_address() wywołuje ResetAdapter() bezwarunkowo, bez
sprawdzanie netif_running(). ResetAdapter() najpierw wywołuje card_stop(), która
ustawia smc->hw.hw_state na ZATRZYMANE, a następnie mac_drv_clear_tx_queue(),
który obsługuje dwie kolejki transmisji:
for (i = KOLEJKA_S; i <= KOLEJKA_A0; i++) {
kolejka = smc->hw.fp.tx[i] ;
...
t = kolejka->tx_curr_get ;
smc->hw.fp.tx[] jest wypełniane tylko przez init_tx(), do której można uzyskać dostęp z
skfp_open() do init_smt() -> init_fddi_driver() -> init_fplus() ->
init_mac() -> init_tx(). Obszar prywatny jest przydzielany i zerowany przez
alloc_fddidev(), więc w interfejsie, który nigdy nie był poruszany w obu przypadkach
wskaźniki kolejki nadal mają wartość NULL. Test hw_state na górze
mac_drv_clear_tx_queue() tego nie wychwytuje, ponieważ card_stop() ma
po prostu ustaw ZATRZYMANY; funkcja przechodzi do pętli i dereferencji
NULL. ResetAdapter() wywołuje samą init_smt(), ale dopiero po
kolejki zostały oczyszczone.
Dlatego ustawienie adresu MAC na wyłączonym interfejsie oops:
zestaw łącza ip dev adres fddi0 02:00:00:00:00:01
BŁĄD: KASAN: null-ptr-deref w mac_drv_clear_tx_queue+0x68/0x2c0 [skfp]
Odczytaj rozmiar 8 pod adresem 0000000000000010 za pomocą zadania ip/302
Zadzwoń do śledzenia:
<ZADANIE>
mac_drv_clear_tx_queue+0x68/0x2c0 [skfp 6c01d4bab63c36978bd0a7d7e90837adb44cc37b]
ResetAdapter+0x29/0x100 [skfp 6c01d4bab63c36978bd0a7d7e90837adb44cc37b]
skfp_ctl_set_mac_address+0x57/0x80 [skfp 6c01d4bab63c36978bd0a7d7e90837adb44cc37b]
adres_netif_set_mac+0x1e4/0x2c0
do_setlink+0x684/0x2680
</ZADANIE>
Adres 0x10 jest przesunięciem tx_curr_get, trzeciego wskaźnika w
struktura s_smt_tx_queue w wersji 64-bitowej. mac_drv_clear_rx_queue(), który
ResetAdapter() wywołuje natychmiast po tym, dereferencje
smc->hw.fp.rx[QUEUE_R1] w ten sam sposób za tym samym nieskutecznym
test stanu_hw; kolejka transmisji po prostu ulega awarii jako pierwsza. Obydwa są
zakryty przez strażnika poniżej.
Pomiń resetowanie adaptera, gdy interfejs nie działa. dev_addr_set() jest
pozostawiony bezwarunkowy, więc nowy adres jest nadal rejestrowany
dev->dev_addr. Jeśli nie zresetujesz adaptera w tym miejscu, nic nie stracisz:
skfp_open() celowo ponownie odczytuje adres fabryczny przy każdym otwarciu,
adres_czytania(smc, NULL);
eth_hw_addr_set(dev, smc->hw.fddi_canon_addr.a);
a powyższy komentarz stwierdza, że ma to na celu odrzucenie dokładnie takiego
zastąpienie adresu w cyklu zamknięcia/otwarcia. Adres ustawiony podczas
interfejs nie działa, nie mógłby przetrwać nawet kolejnego otwarcia
przed tą zmianą, więc osłona nie usuwa żadnych zachowań roboczych. Strzeże
sprzętowa strona ndo_set_mac_address() z netif_running() to
ustalona praktyka; skge_set_mac_address() zrobiło to od czasu zatwierdzenia
2eb3e621c4e0 („skge: ustaw poprawkę łączenia adresów MAC”).
Jest ochrona resetowania jako całości, zamiast sprawdzania kolejek o wartości NULL
także to, czego oczekuje reszta kierowcy. Po poprzednim otwarciu/zamknięciu
wskaźniki kolejki są nieaktualne, ale nie mają wartości NULL, więc nie ma jeszcze awarii
ResetAdapter() wywołuje smt_online() i STI_FBI() („Włącz
Przerwania płyty”), podczas gdy skfp_close() wywołała już free_irq() -
adapter zostanie przywrócony do trybu online bez zainstalowanego modułu obsługi. The
jedynym innym obiektem wywołującym ResetAdapter() jest skfp_interrupt(), który według
budowa przebiega tylko wtedy, gdy urządzenie jest otwarte.
Znaleziony podczas automatycznego testowania sterowników względem emulowanego SysKonnect FDDI
adapter pod jądrem 7.0.0 obsługującym KASAN. Wyzwolenie tego wymaga
CAP_NET_ADMIN.
>_ Referencje
- https://git.kernel.org/stable/c/438131e7ae847e907d345bf504d7e25585561b5c
- https://git.kernel.org/stable/c/5fd0f401b3eee95c93daa35ef99cb03d676031f0
- https://git.kernel.org/stable/c/616ba18b2cfb72b7bea214bdd72df2485b2e37dc
- https://git.kernel.org/stable/c/731db6110b3148331ed8d5d11a564bfd520721d9
- https://git.kernel.org/stable/c/7c8810c2e69c3d9ca6df870b40ae9218e50b4fb1
- https://git.kernel.org/stable/c/822903ed991971780db1db1be31a4f00e2b13e30
- https://git.kernel.org/stable/c/835903bea770ad96ab4322e18d98e00f8e0b39c3
- https://git.kernel.org/stable/c/d6f63fdb298d546a47790cb373db65462c264d04
Dane podatności pochodzą z oficjalnych źródeł (CVE® List / NVD). Opisy po polsku są tłumaczone automatycznie i mogą zawierać nieścisłości – na stronie rekordu można wyświetlić wersję angielską.
This product uses the NVD API but is not endorsed or certified by the NVD.
Copyright © 1999–2026, The MITRE Corporation. CVE is a registered trademark and the CVE logo is a registered trademark of The MITRE Corporation.
CVE Usage: MITRE hereby grants you a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, and distribute Common Vulnerabilities and Exposures (CVE®). Any copy you make for such purposes is authorized provided that you reproduce MITRE's copyright designation and this license in any such copy. ALL DOCUMENTS AND THE INFORMATION CONTAINED THEREIN PROVIDED BY MITRE ARE PROVIDED ON AN "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND.
NVD Terms of Use / CVE® Terms of Use / nvd.nist.gov / cve.org