CVE-2026-98406

Received Received - Intake

Kernel WARN in mac80211 set_bitrate_mask without driver presence

Publication date: 2026-10-14

Last updated on: 2026-10-19

Assigner: kernel.org

Description

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]

CVSS Scores

EPSS Scores

Probability:
Percentile:

Meta Information

Published

2026-10-14

Last Modified

2026-10-19

Generated

2026-10-19

AI Q&A

2026-10-15

EPSS Evaluated

2026-10-18

NVD

CVE-2026-98406

EUVD

EUVD-2026-101055

Affected Vendors & Products

Vendor	Product	Version / Range
Linux	Linux	554a43d5e77e8256aa9685ffd19ad555e6f77979
Linux	Linux	554a43d5e77e8256aa9685ffd19ad555e6f77979
Linux	Linux	554a43d5e77e8256aa9685ffd19ad555e6f77979
Linux	Linux	554a43d5e77e8256aa9685ffd19ad555e6f77979
Linux	Linux	554a43d5e77e8256aa9685ffd19ad555e6f77979
Linux	Linux	554a43d5e77e8256aa9685ffd19ad555e6f77979
Linux	Linux	554a43d5e77e8256aa9685ffd19ad555e6f77979
Linux	Linux	554a43d5e77e8256aa9685ffd19ad555e6f77979
Linux	Linux	3.5

Helpful Resources

Exploitability

CWE

KEV

CWE ID	Description
CWE-UNKNOWN

Attack-Flow Graph

Executive Summary

This vulnerability is in the Linux kernel's wifi subsystem (mac80211). It occurs when the system attempts to set a bitrate mask for a wireless interface that is running but not yet fully registered with the driver. The kernel's ieee80211_set_bitrate_mask() function checks if the interface is running but fails to verify if it is present in the driver, leading to a warning or error when the driver's set_bitrate_mask function is called.

Detection Guidance

This vulnerability is specific to the Linux kernel's mac80211 subsystem and is triggered by certain WiFi operations. Detection would typically involve checking kernel logs for the WARN message: 'Failed check-sdata-in-driver check' or related warnings in driver-ops.h. Commands like 'dmesg | grep -i "check-sdata-in-driver"' or 'journalctl -k | grep -i "WARN"' may help identify the issue.

Impact Analysis

This vulnerability may cause system warnings or errors when wireless interface settings are modified, particularly during interface bringup or teardown. It could disrupt network connectivity or cause instability in systems using affected Linux kernel versions.

Compliance Impact

This vulnerability does not directly affect compliance with GDPR, HIPAA, or similar standards. It is a Linux kernel WiFi driver issue causing a warning during interface teardown or bringup, not a data privacy or security breach.

Mitigation Strategies

Apply the Linux kernel patch that resolves this issue. Update to a kernel version containing the fix for CVE-2026-98406. If immediate patching is not possible, avoid using wext ioctls like SIOCSIWRATE, which can trigger the vulnerability during interface operations.

Hi! I’m here to help you understand CVE-2026-98406. Ask me anything about the vulnerability, its impact, or mitigation strategies.

0/70