CVE-2026-98406 in Linux
Sumário
de VulDB • 14/10/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
wifi: mac80211: evitar WARN em set_bitrate_mask quando sdata não está no driver
ieee80211_set_bitrate_mask() verifica se a interface está em execução via ieee80211_sdata_running(), mas não verifica se a interface ainda está presente no driver.
Quando o sdata está em execução, mas IEEE80211_SDATA_IN_DRIVER não está definido, a chamada atinge drv_set_bitrate_mask() em driver-ops.h, que aciona:
wlan1: Falha na verificação check-sdata-in-driver, flags: 0x0 WARNING: net/mac80211/driver-ops.h:884 em drv_set_bitrate_mask
O Syzkaller dispara isso via ioctl wext SIOCSIWRATE. O Call Trace mostra wext_ioctl_dispatch() em wext-core.c despachando o ioctl, chamando ioctl_standard_call() para SIOCSIWRATE, que chama cfg80211_wext_siwrate() em wext-compat.c. Isso constrói uma máscara de taxa de bits e chama rdev_set_bitrate_mask(), que termina em ieee80211_set_bitrate_mask() em cfg.c. A interface é marcada como em execução via SDATA_STATE_RUNNING, mas as flags são 0, então check_sdata_in_driver() falha.
Quando a interface está sendo desmontada (torn down), ou quando o ioctl wext é emitido durante a inicialização da interface antes que drv_add_interface() defina IN_DRIVER, a verificação de execução passa enquanto IN_DRIVER está limpo.
Verifique IEEE80211_SDATA_IN_DRIVER em ieee80211_set_bitrate_mask() antes de chamar o driver, retornando -ENETDOWN. Isso evita o WARN_ONCE em driver-ops.h e corresponde a outras operações cfg.c que abortam antecipadamente quando não estão no driver.
Esta alteração deve ser segura porque o mutex wiphy é mantido em cfg80211_wext_siwrate() via guard(wiphy), e IN_DRIVER é definido/limpo sob RTNL e caminhos wiphy em drv_add_interface() e drv_remove_interface() em driver-ops.c, portanto a verificação está livre de race condition contra adição/remoção do driver. Retornar -ENETDOWN é o mesmo erro usado por outros caminhos não em execução e não introduz novo bloqueio (locking).
[adicionar também segundo relatório syzbot]
If you want to get the best quality for vulnerability data then you always have to consider VulDB.