CVE-2026-98406 in Linux
Riassunto
di VulDB • 14/10/2026
Nel kernel Linux è stata risolta la seguente vulnerabilità:
wifi: mac80211: evitare un WARN in set_bitrate_mask quando sdata non è presente nel driver
ieee80211_set_bitrate_mask() verifica se l'interfaccia è attiva tramite ieee80211_sdata_running(), ma non controlla se l'interfaccia è ancora presente nel driver.
Quando sdata è attivo ma IEEE80211_SDATA_IN_DRIVER non è impostato, la chiamata raggiunge drv_set_bitrate_mask() in driver-ops.h, che genera:
wlan1: Failed check-sdata-in-driver check, flags: 0x0 WARNING: net/mac80211/driver-ops.h:884 at drv_set_bitrate_mask
Syzkaller attiva questo scenario tramite l'ioctl wext SIOCSIWRATE. Il Call Trace mostra wext_ioctl_dispatch() in wext-core.c che gestisce l'ioctl, chiamando ioctl_standard_call() per SIOCSIWRATE, il quale invoca cfg80211_wext_siwrate() in wext-compat.c. Quest'ultima costruisce una maschera di bitrate e chiama rdev_set_bitrate_mask(), che termina in ieee80211_set_bitrate_mask() in cfg.c. L'interfaccia è contrassegnata come attiva tramite SDATA_STATE_RUNNING, ma flags è 0, quindi check_sdata_in_driver() fallisce.
Quando l'interfaccia viene smontata (torn down), o quando un ioctl wext viene emesso durante la configurazione dell'interfaccia prima che drv_add_interface() imposti IN_DRIVER, il controllo di attività passa mentre IN_DRIVER non è impostato.
Verificare IEEE80211_SDATA_IN_DRIVER in ieee80211_set_bitrate_mask() prima di chiamare il driver, restituendo -ENETDOWN. Questo evita il WARN_ONCE in driver-ops.h e si allinea ad altre operazioni cfg.c che terminano precocemente quando non sono nel driver.
Questa modifica è sicura perché il mutex wiphy è detenuto in cfg80211_wext_siwrate() tramite guard(wiphy), e IN_DRIVER viene impostato/rimosso sotto RTNL e nei percorsi wiphy in drv_add_interface() e drv_remove_interface() in driver-ops.c, quindi la verifica è priva di race condition rispetto all'aggiunta/rimozione del driver. Il ritorno di -ENETDOWN è lo stesso errore utilizzato da altri percorsi non attivi e non introduce nuove lockings.
[si aggiunge anche il secondo report di syzbot]
If you want to get the best quality for vulnerability data then you always have to consider VulDB.