CVE-2026-98810: wifi: mac80211: fix slab-out-of-bounds read in ieee80211_monitor_select_queue()
In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: fix slab-out-of-bounds read in ieee80211monitorselectqueue()
ieee80211monitorselectqueue() 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 AFPACKET sends a packet large enough to become non-linear, the 802.11 header at skb->data + lenrthdr 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->framecontrol, as the kernel reads beyond the allocated skb head buffer:
BUG: KASAN: slab-out-of-bounds in ieee80211monitorselectqueue+0x1ed/0x220
syzbot has hit the same issues.
Fix this by checking skbheadlen(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 ieee80211validateradiotaplen() which has the same class of bug: it uses skb->len to validate accesses to skb->data, and to the corresponding checks in ieee80211monitorstartxmit(): for drivers advertising NETIFFSG the skb is not linearized before ndostartxmit, so the 802.11 header can be read past the linear buffer there as well.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
In ieee80211_monitor_select_queue(), ieee80211_validate_radiotap_len(), and the corresponding checks in ieee80211_monitor_start_xmit(), use skb_headlen(skb) instead of skb->len when validating accesses to skb->data, ensuring the required bytes are present in the linear portion of the skb.
Event History
Frequently Asked Questions
What conditions are needed to trigger the out-of-bounds read?
A packet sent through AF_PACKET must be large enough to be represented with non-linear fragments while appearing long enough according to skb->len. The 802.11 header or radiotap data then extends beyond the linear skb head buffer when the affected code dereferences skb->data.
How can I tell whether this has already occurred?
Kernel memory-safety instrumentation may report a KASAN slab-out-of-bounds error in ieee80211_monitor_select_queue(). The reported condition is an access beyond the allocated skb head buffer while reading hdr->frame_control.
What does the fix change?
The fix replaces skb->len validation with skb_headlen(skb) before dereferencing pointers into skb->data. The same validation correction is applied to ieee80211_validate_radiotap_len(), which has the same non-linear skb handling issue.
Is a workaround provided if the fix cannot be applied immediately?
No compensating configuration workaround is specified in the available information. The described remediation is to use code that validates the linear skb region with skb_headlen(skb).