CVE-2026-98406: wifi: mac80211: avoid WARN in set_bitrate_mask when sdata not in driver

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

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

ieee80211setbitratemask() checks if the interface is running via ieee80211sdatarunning(), but it does not check if the interface is still present in the driver.

When sdata is running but IEEE80211SDATAINDRIVER is not set, the call reaches drvsetbitratemask() in driver-ops.h which hits

wlan1: Failed check-sdata-in-driver check, flags: 0x0 WARNING: net/mac80211/driver-ops.h:884 at drvsetbitratemask

Syzkaller triggers this via wext SIOCSIWRATE ioctl. The Call Trace shows wextioctldispatch() in wext-core.c dispatching the ioctl, calling ioctlstandardcall() for SIOCSIWRATE, which calls cfg80211wextsiwrate() in wext-compat.c. That builds a bitrate mask and calls rdevsetbitratemask() which ends up in ieee80211setbitratemask() in cfg.c. The interface is marked running via SDATASTATERUNNING but flags is 0, so checksdataindriver() fails.

When the interface is being torn down, or when wext ioctl is issued during interface bringup before drvaddinterface() sets INDRIVER, the running check passes while INDRIVER is clear.

Check IEEE80211SDATAINDRIVER in ieee80211setbitratemask() before calling the driver, returning -ENETDOWN. This avoids the WARNONCE 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 cfg80211wextsiwrate() via guard(wiphy), and INDRIVER is set/cleared under RTNL and wiphy paths in drvaddinterface() and drvremoveinterface() 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]