Live › vulnerability › CVE-2026-98810
Go to dashboardA bounds check in the Linux kernel's mac80211 Wi-Fi monitor-mode code uses the total packet length instead of the linear buffer length, so a large AF_PACKET frame can cause an out-of-bounds read. The sources do not state what an attacker gains beyond a kernel memory read.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-23 21:57 UTC. All times on this page are UTC.
Systems running a Linux kernel with mac80211 Wi-Fi support where monitor-mode interfaces are used and AF_PACKET sockets can send frames. The sources do not say which kernel versions are affected or how common the configuration is, so systems without Wi-Fi hardware or monitor interfaces are likely not exposed.
No product ranges from the sources yet.
uname -r and compare against the fixed kernel release in your distribution's advisory: unknownlsmod | grep mac80211; unknown if the sources do not say moreEach row is the first time that source carried this signal. The analyst’s rows are its own findings.
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.
This page as .md · .json · in your agent: get_signal("CVE-2026-98810")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.