Cloudanix VulnDB

CVE-2026-98810

None

CVSS

—

EPSS

0.2%

Published

Oct 18, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in the Linux kernel's wireless monitoring code can let a specially crafted network packet read memory it should not, which might crash the system or leak small amounts of data.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Data Exposure
Component
OS kernel
Class
Memory Corruption
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

Slab-out-of-bounds read in mac80211 monitor path when skb->len check passes but 802.11 header spans beyond linear head buffer in non-linear skbs, allowing access past allocated skb head.

Why it matters to the business

Kernel memory corruption risk on Linux wireless systems using monitor mode or radiotap, potentially causing crashes or limited information disclosure; low exploitation probability but affects broad kernel deployments five days after disclosure.

How an attack unfolds

Attacker crafts oversized packet via AF_PACKET socket so it becomes non-linear; ieee80211_monitor_select_queue, ieee80211_validate_radiotap_len or ieee80211_monitor_start_xmit then dereference skb->data beyond linear region, triggering KASAN-detected out-of-bounds read.

How to fix it

Apply upstream fix replacing skb->len checks with skb_headlen(skb) in ieee80211_monitor_select_queue, ieee80211_validate_radiotap_len and ieee80211_monitor_start_xmit; rebuild and deploy updated kernel; disable monitor mode where possible until patched.

How to confirm the fix worked

Confirm presence of skb_headlen(skb) check in the three functions; run syzbot-style reproducer or KASAN-enabled test with fragmented monitor packets; verify no slab-out-of-bounds reports on patched kernel.

Typical attack path

  1. Create raw AF_PACKET socket and send packet large enough to trigger page fragmentation
  2. Kernel routes packet through mac80211 monitor queue selection or start_xmit
  3. skb->len validation succeeds while header lies outside linear head buffer
  4. Dereference of frame_control or radiotap fields reads past slab allocation

How to detect it

Search kernel logs for KASAN: slab-out-of-bounds in ieee80211_monitor_select_queue, ieee80211_validate_radiotap_len or ieee80211_monitor_start_xmit; inspect crash dumps for skb head buffer overruns triggered by monitor path.

  • BUG: KASAN: slab-out-of-bounds in ieee80211_monitor_select_queue
  • ieee80211_monitor_select_queue+0x1ed/0x220
  • skb_headlen check missing in mac80211 monitor path

What your security team should do

  • Prioritize kernel update on all systems exposing wireless monitor interfaces
  • Add KASAN or kernel crash monitoring for ieee80211_monitor_select_queue symbols
  • Restrict AF_PACKET usage on wireless nodes until remediation
  • Track EPSS and KEV updates given recent publication

The record

In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: fix slab-out-of-bounds read in ieee80211_monitor_select_queue() ieee80211_monitor_select_queue() validates the skb length using skb->len before dereferencing pointers into skb->data to access the 802.11 header. However, skb->len includes data in both the linear head buffer and non-linear fragments/pages. When AF_PACKET sends a packet large enough to become non-linear, the 802.11 header at skb->data + len_rthdr may extend past the linear head buffer even though skb->len appears sufficient. This leads to a slab-out-of-bounds read when accessing hdr->frame_control, as the kernel reads beyond the allocated skb head buffer: BUG: KASAN: slab-out-of-bounds in ieee80211_monitor_select_queue+0x1ed/0x220 syzbot has hit the same issues. Fix this by checking skb_headlen(skb) (which gives the length of the linear data region) instead of skb->len before dereferencing skb->data pointers. This ensures the required bytes are actually present in the linear portion of the skb. Apply the same fix to ieee80211_validate_radiotap_len() which has the same class of bug: it uses skb->len to validate accesses to skb->data, and to the corresponding checks in ieee80211_monitor_start_xmit(): for drivers advertising NETIF_F_SG the skb is not linearized before ndo_start_xmit, so the 802.11 header can be read past the linear buffer there as well.

Affected packages

Ecosystem Package Introduced Fixed