<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://db.gcve.eu/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-11-03T03:38:18.206486+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>info@gcve.eu</email>
  </author>
  <link href="https://db.gcve.eu" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://db.gcve.eu/vuln/cve-2026-98810</id>
    <title>CVE-2026-98810 — wifi: mac80211: fix slab-out-of-bounds read in ieee80211_monitor_select_queue()</title>
    <updated>2026-11-03T03:38:18.208063+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> Linux</p>
<p>In the Linux kernel, the following vulnerability has been resolved:</p>
<p>wifi: mac80211: fix slab-out-of-bounds read in ieee80211_monitor_select_queue()</p>
<p>ieee80211_monitor_select_queue() validates the skb length using skb-&gt;len
before dereferencing pointers into skb-&gt;data to access the 802.11 header.
However, skb-&gt;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-&gt;data + len_rthdr may extend
past the linear head buffer even though skb-&gt;len appears sufficient.</p>
<p>This leads to a slab-out-of-bounds read when accessing hdr-&gt;frame_control,
as the kernel reads beyond the allocated skb head buffer:</p>
<p>BUG: KASAN: slab-out-of-bounds in ieee80211_monitor_select_queue+0x1ed/0x220</p>
<p>syzbot has hit the same issues.</p>
<p>Fix this by checking skb_headlen(skb) (which gives the length of the
linear data region) instead of skb-&gt;len before dereferencing skb-&gt;data
pointers. This ensures the required bytes are actually present in the
linear portion of the skb.</p>
<p>Apply the same fix to ieee80211_validate_radiotap_len() which has the
same class of bug: it uses skb-&gt;len to validate accesses to skb-&gt;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.</p></div>
    </content>
    <link href="https://db.gcve.eu/vuln/cve-2026-98810"/>
  </entry>
</feed>
