<?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://vulnerability.circl.lu/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-09-30T03:39:35.123338+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>info@circl.lu</email>
  </author>
  <link href="https://vulnerability.circl.lu" 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://vulnerability.circl.lu/vuln/cve-2026-64515</id>
    <title>CVE-2026-64515 — wifi: mac80211: fix MLE defragmentation</title>
    <updated>2026-09-30T03:39:35.125231+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 MLE defragmentation</p>
<p>If either reconf or EPCS multi-link element (MLE) is contained in
a non-transmitted profile, the defragmentation routine is called
with a pointer to the defragmented copy, but the original elements.</p>
<p>This is incorrect for two reasons:
 - if the original defragmentation was needed, it will not find the
   correct data
 - if the original frame is at a higher address, the parsing will
   potentially overrun the heap data (though given the layout of
   the buffers, only into the new defragmentation buffer, and then
   it has to stop and fail once that's filled with copied data.</p>
<p>Fix it by tracking the container along with the pointer and in
doing so also unify the two almost identical defragmentation
routines.</p></div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/cve-2026-64515"/>
  </entry>
</feed>
