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]
Published: 2026-10-14
Score: 5.5 Medium
EPSS: < 1% Very Low
KEV: No
Impact: Kernel warning that may produce log noise
Action: Apply Patch
AI Analysis

Impact

The flaw exists in the Linux kernel's mac80211 subsystem. When a wireless interface is marked running but has not yet been registered with the driver, the ieee80211_set_bitrate_mask() handler does not verify the IEEE80211_SDATA_IN_DRIVER flag before calling drv_set_bitrate_mask(). This omission triggers a WARN_ONCE in driver‑ops.h and logs a "Failed check‑sdata‑in‑driver" message. The vulnerability does not enable code execution or privilege escalation; it primarily results in noisy kernel logs and could degrade diagnostic efforts.

Affected Systems

All Linux kernel builds released before the commit that inserts the driver presence check. This includes the upstream kernel sources and the kernel packages distributed by major Linux distributions such as Debian, Ubuntu, RHEL, CentOS, SUSE, Fedora, and others, until a kernel containing the patch is installed.

Risk and Exploitability

The CVSS score of 5.5 indicates moderate severity. The EPSS score is less than 1% and the vulnerability is not listed in CISA’s KEV catalog, implying a low probability of exploitation. Based on the description, the likely attack vector is a local privileged user who can invoke the SIOCSIWRATE ioctl while a wireless interface is being brought up or torn down. The exploit would only produce kernel warning messages and not grant further access or affect system integrity.

Generated by OpenCVE AI on October 17, 2026 at 02:41 UTC.

Remediation

No solution or workaround provided in the CVE record.

OpenCVE Recommended Actions

  • Upgrade the Linux kernel to a version that includes the commit adding the IEEE80211_SDATA_IN_DRIVER check, or apply the supplied patch to the kernel source.
  • If a kernel upgrade cannot be performed promptly, avoid issuing the SIOCSIWRATE ioctl while the wireless interface is transitioning, ensuring that the interface is fully registered with the driver before calling the ioctl.
  • Monitor kernel logs for repeated "Failed check‑sdata‑in‑driver" warnings and adjust logging verbosity or kernel debugging settings if necessary to reduce noise.

Generated by OpenCVE AI on October 17, 2026 at 02:41 UTC.

Tracking

Sign in to view the affected projects.

Advisories
Source ID Title
Debian DLA Debian DLA DLA-4841-1 linux security update
Debian DLA Debian DLA DLA-4850-1 linux-6.12 security update
Debian DSA Debian DSA DSA-6568-1 linux security update
Ubuntu USN Ubuntu USN USN-8961-1 Linux kernel vulnerabilities
History

Sat, 17 Oct 2026 00:30:00 +0000

Type Values Removed Values Added
Weaknesses CWE-703

Fri, 16 Oct 2026 12:30:00 +0000

Type Values Removed Values Added
Weaknesses CWE-617
References
Metrics threat_severity

None

cvssV3_1

{'score': 5.5, 'vector': 'CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H'}

threat_severity

Low


Fri, 16 Oct 2026 07:45:00 +0000

Type Values Removed Values Added
Weaknesses CWE-703

Thu, 15 Oct 2026 23:00:00 +0000

Type Values Removed Values Added
Weaknesses CWE-20
CWE-398

Thu, 15 Oct 2026 06:30:00 +0000

Type Values Removed Values Added
Weaknesses CWE-20
CWE-398

Wed, 14 Oct 2026 13:45:00 +0000

Type Values Removed Values Added
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]
Title wifi: mac80211: avoid WARN in set_bitrate_mask when sdata not in driver
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-10-19T09:18:59.519Z

Reserved: 2026-09-25T10:25:14.347Z

Link: CVE-2026-98406

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-10-14T14:17:51.710

Modified: 2026-10-19T10:18:45.657

Link: CVE-2026-98406

cve-icon Redhat

Severity : Low

Publid Date: 2026-10-14T00:00:00Z

Links: CVE-2026-98406 - Bugzilla

cve-icon OpenCVE Enrichment

Updated: 2026-10-19T18:45:01Z

Weaknesses