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]