CVE-2026-98406

In the Linux kernel, the following vulnerability has been resolved:

wifi: mac80211: avoid WARN in set_bitrate_mask when sdata not in driver

ieee80211_set_bitrate_mask() checks if the interface is running via

ieee80211_sdata_running(), but it does not check if the interface is

still present in the driver.

When sdata is running but IEEE80211_SDATA_IN_DRIVER is not set, the

call reaches drv_set_bitrate_mask() in driver-ops.h which hits

wlan1: Failed check-sdata-in-driver check, flags: 0x0

WARNING: net/mac80211/driver-ops.h:884 at drv_set_bitrate_mask

Syzkaller triggers this via wext SIOCSIWRATE ioctl. The Call Trace shows

wext_ioctl_dispatch() in wext-core.c dispatching the ioctl, calling

ioctl_standard_call() for SIOCSIWRATE, which calls cfg80211_wext_siwrate()

in wext-compat.c. That builds a bitrate mask and calls

rdev_set_bitrate_mask() which ends up in ieee80211_set_bitrate_mask() in

cfg.c. The interface is marked running via SDATA_STATE_RUNNING but

flags is 0, so check_sdata_in_driver() fails.

When the interface is being torn down, or when wext ioctl is issued

during interface bringup before drv_add_interface() sets IN_DRIVER, the

running check passes while IN_DRIVER is clear.

Check IEEE80211_SDATA_IN_DRIVER in ieee80211_set_bitrate_mask() before

calling the driver, returning -ENETDOWN. This avoids the WARN_ONCE in

driver-ops.h and matches other cfg.c operations that bail early when not

in driver.

This change should be safe because wiphy mutex is held in

cfg80211_wext_siwrate() via guard(wiphy), and IN_DRIVER is set/cleared

under RTNL and wiphy paths in drv_add_interface() and

drv_remove_interface() in driver-ops.c, so the check is race-free

against driver add/remove. Returning -ENETDOWN is the same error other

not-running paths use and does not introduce new locking.

[also add second syzbot report]