CVE-2026-98699

What it actually does

Use-after-free in Linux kernel mac80211 mesh_fast_tx_cache where raw mesh_path pointers remain after deletion flushes the cache and performs kfree_rcu; concurrent lookups can re-insert entries pointing to freed memory because the DELETED flag was not set before the flush and checks were not serialized under the cache walk lock.

Why it matters to the business

Wireless mesh networking on Linux systems can experience kernel crashes, memory corruption, or potential local privilege escalation, disrupting connectivity for routers, access points, and IoT devices using 802.11s and requiring emergency patching across fleets.

How an attack unfolds

An attacker with the ability to influence mesh path creation and deletion (via crafted 802.11s frames or local process interaction) triggers concurrent fast-tx cache insertion while a path is being deleted; the window between flush and kfree_rcu allows a dangling pointer to be stored and later dereferenced, leading to UAF.

How to fix it

Apply the upstream patch that sets MESH_PATH_DELETED under the cache walk lock before flushing, uses WRITE_ONCE for flag updates, and skips insertion for deleted paths; rebuild and deploy updated Linux kernels containing the fix to all affected systems.

How to confirm the fix worked

Confirm the patched kernel source contains the MESH_PATH_DELETED checks and WRITE_ONCE usage in mesh_fast_tx.c; boot test with mesh networking enabled and monitor for absence of UAF warnings in dmesg under path churn workloads.

Typical attack path

1. Establish or manipulate 802.11s mesh paths on a vulnerable Linux system
2. Trigger path deletion while fast_tx_cache lookups are active
3. Force re-insertion of a cache entry after flush but before RCU grace period
4. Dereference the freed mesh_path structure via subsequent tx operations

How to detect it

Search kernel logs for mac80211 UAF or slab-out-of-bounds warnings mentioning mesh_path or mesh_fast_tx; inspect wireless interface statistics for unexpected path churn and correlate with process activity that manipulates mesh routes.

What your security team should do

• Prioritize kernel updates for all Linux systems participating in 802.11s meshes
• Restrict mesh peer authentication to trusted nodes until patched
• Enable kernel hardening features such as KASAN and hardened usercopy in test environments
• Monitor for mac80211 mesh-related oops and schedule fleet-wide reboots after patching