Cloudanix VulnDB

CVE-2026-98406

None

CVSS

—

EPSS

0.2%

Published

Oct 14, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A wireless networking bug in Linux can trigger system warnings when certain commands arrive while a connection is still starting or shutting down.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Low
Impact
Denial Of Service
Component
OS kernel
Class
Improper Input Validation
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

Missing validation for IEEE80211_SDATA_IN_DRIVER flag in ieee80211_set_bitrate_mask allows a WARN_ONCE to be hit in drv_set_bitrate_mask when an interface reports as running via ieee80211_sdata_running but has not completed drv_add_interface.

Why it matters to the business

Wireless network interfaces may emit kernel warnings or experience brief instability during bring-up or teardown when legacy wireless extension ioctls are used, potentially affecting connectivity reliability in Linux-based systems.

How an attack unfolds

An attacker or fuzzer issues an SIOCSIWRATE wext ioctl via cfg80211_wext_siwrate during the window when SDATA_STATE_RUNNING is set but IN_DRIVER is clear, traversing wext_ioctl_dispatch to ieee80211_set_bitrate_mask and triggering the driver-ops check failure.

How to fix it

Apply the upstream fix that adds an explicit IEEE80211_SDATA_IN_DRIVER check in ieee80211_set_bitrate_mask returning -ENETDOWN before invoking the driver callback.

How to confirm the fix worked

Confirm the added driver-state check exists in cfg.c and reproduce the original ioctl sequence to verify no WARN is emitted.

Typical attack path

  1. Send SIOCSIWRATE ioctl on a mac80211 interface
  2. Interface reaches SDATA_STATE_RUNNING state before drv_add_interface completes
  3. ieee80211_set_bitrate_mask skips running-state check but reaches drv_set_bitrate_mask
  4. check_sdata_in_driver fails and emits WARN_ONCE

How to detect it

Inspect kernel logs and dmesg for messages containing 'Failed check-sdata-in-driver' or 'drv_set_bitrate_mask' originating from net/mac80211 during interface state transitions.

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

What your security team should do

  • Prioritize patching affected Linux kernels once fixed versions are released
  • Review wireless interface bring-up scripts for use of legacy wext ioctls
  • Enable kernel warning logging and alerting for mac80211 driver-ops messages

The record

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]

Affected packages

Ecosystem Package Introduced Fixed