Cloudanix VulnDB

CVE-2026-98936

None

CVSS

—

EPSS

0.2%

Published

Oct 23, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A wireless driver bug can stop new devices from joining the network after restarts until the system is fixed or rebooted.

Exploitation
Other
Attacker needs
None
Complexity
Theoretical
Impact
Denial Of Service
Component
OS kernel
Class
Denial of service
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Failure to reset the num_stations accounting variable in the ath11k WiFi driver struct on hardware restart leaves the counter at its prior value, causing the driver to incorrectly reject new station associations once the perceived limit is reached.

Why it matters to the business

Wireless network availability can be lost after driver restarts, blocking new device connections and requiring manual intervention or reboots to restore service.

How an attack unfolds

An attacker or environmental condition triggers repeated hardware restarts in the ath11k driver; the unreleased station count then blocks legitimate new associations, producing a denial-of-service condition for Wi-Fi clients.

How to fix it

Update the Linux kernel to the version containing the ath11k_mac_op_start change that clears ar->num_stations on every hardware start.

How to confirm the fix worked

After applying the fix, trigger multiple hardware restarts and verify that new stations can still associate without the 'refusing to associate station' message or ieee80211_reconfig_stations warnings appearing in the kernel log.

Typical attack path

  1. Induce or wait for ath11k hardware restart events
  2. Attempt new station or mesh peer association
  3. Driver refuses association with 'too many connected already' error
  4. Service remains unavailable until manual reset

How to detect it

Search kernel logs and dmesg for the strings 'refusing to associate station: too many connected already', 'Failed to add station', and the ieee80211_reconfig_stations warning stack trace following any ath11k hardware restart events.

  • refusing to associate station: too many connected already (128)
  • ieee80211_reconfig_stations+0x98/0xc0
  • Failed to add station
  • ath11k_pci.*refusing to associate station

What your security team should do

  • Prioritize kernel update for systems using ath11k hardware within the next maintenance window
  • Add kernel log monitoring for ieee80211_reconfig_stations and 'too many connected already' strings
  • Test Wi-Fi stability under repeated restart conditions in a lab environment

The record

In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: reset ar->num_stations on hardware start When (multiple) hw restart occurs, we end up in a situation where we cannot accept new stations / mesh peers. This seems to be the 'num_stations' in 'struct ath11k' that did not get reset properly in this case. In ath11k_mac_op_start(), it was indeed the only accounting var that did not get reset so let's clear it too. This avoids problems like those: [1248828.088023] WARNING: CPU: 0 PID: 12281 at net/mac80211/util.c:1682 ieee80211_reconfig_stations+0x98/0xc0 [1248828.088115] Call trace: [1248828.088116] ieee80211_reconfig_stations+0x98/0xc0 (P) [1248828.088119] ieee80211_reconfig+0x774/0x1438 [1248828.088123] ieee80211_restart_work+0x10c/0x178 [1248828.088127] process_one_work+0x178/0x3c0 [1248828.088130] worker_thread+0x280/0x440 [1248828.088133] kthread+0xe0/0xf8 [1248828.088137] ret_from_fork+0x10/0x20 [1248828.088141] ---[ end trace 0000000000000000 ]--- [1248836.686604] ath11k_pci 0000:04:00.0: refusing to associate station: too many connected already (128) [1248836.686609] ath11k_pci 0000:04:00.0: Failed to add station: xx:xx:xx:xx:xx:xx for VDEV: 1 Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.9.0.1-01977-QCAHKSWPL_SILICONZ-1

Affected packages

Ecosystem Package Introduced Fixed