CVE-2026-98406 in Linux
Summary
by MITRE • 10/15/2026
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]
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/15/2026
The Linux kernel wireless subsystem contains a logic flaw within the mac80211 stack that can trigger an unintended warning condition during bitrate mask configuration operations. Specifically, the function ieee80211_set_bitrate_mask performs a check to determine if the network interface is currently running by invoking ieee80211_sdata_running(). However, this validation is incomplete because it fails to verify whether the software data structure representing the interface remains registered and active within the underlying wireless driver. This oversight creates a race condition window where an interface may be marked as logically running while simultaneously being absent from the driver's internal state management structures. When such a mismatch occurs, subsequent calls to drv_set_bitrate_mask result in a failure of the check_sdata_in_driver assertion, leading to the emission of a WARN_ONCE message indicating that the software data structure is not present in the driver despite appearing active at higher abstraction layers.
This vulnerability can be triggered through legacy wireless extensions mechanisms, specifically via the SIOCSIWRATE ioctl interface. The execution path begins with wext_ioctl_dispatch handling the incoming system call and routing it to cfg80211_wext_siwrate for standard rate configuration processing. This function constructs a bitrate mask and invokes rdev_set_bitrate_mask, which ultimately reaches ieee80211_set_bitrate_mask in the mac80211 core code. During interface teardown sequences or during the initial bringup phase before drv_add_interface has executed to set the IN_DRIVER flag, the SDATA_STATE_RUNNING bit may be set while the driver-specific flags remain zero. Consequently, the running check passes but the internal presence check fails, exposing the kernel to unnecessary warning logs and potential instability if further operations assume valid driver context.
From a security perspective, this issue is classified under CWE-691 as an Improper Control Flow Conduction, where the application logic proceeds into a code path that assumes a state which does not exist in reality. The operational impact primarily involves log spamming through WARN_ONCE messages and potential confusion for system administrators or automated monitoring tools interpreting kernel warnings as critical failures. While direct exploitation leading to arbitrary code execution is unlikely due to the nature of the check, the presence of such warnings can mask more serious issues or indicate a deeper state inconsistency that could be leveraged in conjunction with other vulnerabilities. The vulnerability aligns with ATT&CK technique T1078, specifically related to valid accounts and system configuration states where an attacker might manipulate interface states to cause denial of service through resource exhaustion via repeated warning generation or to probe for kernel stability weaknesses.
The remediation involves modifying ieee80211_set_bitrate_mask to explicitly check the IEEE80211_SDATA_IN_DRIVER flag before attempting to communicate with the driver hardware abstraction layer. If this flag is not set, the function returns -ENETDOWN, which is a standard error code indicating that the network interface is down or unavailable for operation. This approach ensures consistency with other operations in cfg.c that similarly bail out early when the interface is not properly registered with the driver. The fix is considered safe because it operates within existing synchronization primitives; specifically, the wiphy mutex held by guard(wiphy) during cfg80211_wext_siwrate execution prevents race conditions against drv_add_interface and drv_remove_interface calls that modify the IN_DRIVER flag under RTNL lock protection. This ensures thread safety without introducing new locking dependencies or performance overheads.
To mitigate this vulnerability, system administrators should ensure that their Linux kernel is updated to a version containing this patch. For environments where immediate patching is not feasible, limiting access to wireless configuration tools and monitoring for excessive WARN messages in dmesg output can help detect potential abuse attempts. Additionally, ensuring proper interface lifecycle management through standardized network management services rather than direct ioctl manipulation reduces the likelihood of triggering these race conditions during bringup or teardown phases. Regular auditing of kernel logs for repeated warnings related to driver operations is recommended as a defensive measure against state inconsistency issues in wireless subsystems.