Cloudanix VulnDB

CVE-2026-98705

None

CVSS

—

EPSS

0.2%

Published

Oct 18, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in Linux wireless mesh networking code can let too many network routes be created, which might make certain Wi-Fi setups unstable or run out of resources.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Other
Component
OS kernel
Class
Improper Input Validation
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Proxy path operations fail to reserve or correctly account against the shared interface mpaths counter, allowing mesh_path_add() to bypass the MESH_MAX_MPATHS limit after proxy churn decrements the counter below its true occupancy.

Why it matters to the business

Mesh-enabled wireless interfaces on Linux systems may accept more paths than intended, risking memory exhaustion, performance degradation, or instability in large-scale or dynamic Wi-Fi mesh deployments; urgency remains low given five days of public exposure and negligible exploitation probability.

How an attack unfolds

An attacker would need to trigger repeated proxy-path additions and removals on a mesh interface to drive the counter negative, then issue additional legitimate mesh-path requests that the flawed accounting now permits beyond the design limit.

How to fix it

Update to a Linux kernel containing the referenced fix that reserves quota before proxy-path allocation and releases it on failure; no per-package fixed versions are listed in the source data.

How to confirm the fix worked

Inspect the mac80211 mesh code for the presence of quota reservation in mpp_path_add() and unified counter usage between mesh and proxy tables; confirm MESH_MAX_MPATHS enforcement holds under proxy-path churn in testing.

Typical attack path

  1. Gain adjacency on a target mesh interface
  2. Cause repeated proxy-path churn via crafted or timed MPP announcements
  3. Force the interface counter below the actual number of installed paths
  4. Add further mesh paths that now exceed MESH_MAX_MPATHS

How to detect it

No public exploitation activity is known; examine kernel logs for mesh-path allocation failures or counter anomalies on systems running vulnerable mac80211 builds, and correlate with wireless interface configuration changes.

What your security team should do

  • Prioritize kernel updates on any systems exposing 802.11s mesh interfaces
  • Monitor EPSS and KEV status for changes given the five-day publication window
  • Review mesh configuration to reduce reliance on dynamic proxy paths where possible

The record

In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: account proxy paths against the mesh path limit Proxy-path churn can drive the interface path counter negative and let later mesh path additions exceed MESH_MAX_MPATHS. mesh_path_free_rcu() decrements the interface mpaths counter for entries from both the mesh and proxy path tables, but mpp_path_add() never reserves a slot in that counter. Removing or expiring a proxy path therefore returns a slot that was never charged. mesh_path_add() uses the same counter to enforce MESH_MAX_MPATHS, so once it falls below the number of installed paths the limit no longer holds. Reserve the shared quota before allocating a proxy path and release it on every unsuccessful addition. Mesh and proxy paths now share one 1024-entry budget, so mpp_path_add() can return -ENOSPC at that limit.

Affected packages

Ecosystem Package Introduced Fixed