<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://vulnerability.circl.lu</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Tue, 29 Sep 2026 06:34:54 +0000</lastBuildDate>
    <item>
      <title>CVE-2026-31504 — net: fix fanout UAF in packet_release() via NETDEV_UP race</title>
      <link>https://vulnerability.circl.lu/vuln/cve-2026-31504</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Linux, Siemens SIMATIC S7-1500 CPU 1518-4 PN/DP MFP, Siemens SIMATIC S7-1500 CPU 1518F-4 PN/DP MFP, Siemens SIPLUS S7-1500 CPU 1518-4 PN/DP MFP&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;net: fix fanout UAF in packet_release() via NETDEV_UP race&lt;/p&gt;
&lt;p&gt;`packet_release()` has a race window where `NETDEV_UP` can re-register a
socket into a fanout group&amp;#39;s `arr[]` array. The re-registration is not
cleaned up by `fanout_release()`, leaving a dangling pointer in the fanout
array.
`packet_release()` does NOT zero `po-&amp;gt;num` in its `bind_lock` section.
After releasing `bind_lock`, `po-&amp;gt;num` is still non-zero and `po-&amp;gt;ifindex`
still matches the bound device. A concurrent `packet_notifier(NETDEV_UP)`
that already found the socket in `sklist` can re-register the hook.
For fanout sockets, this re-registration calls `__fanout_link(sk, po)`
which adds the socket back into `f-&amp;gt;arr[]` and increments `f-&amp;gt;num_members`,
but does NOT increment `f-&amp;gt;sk_ref`.&lt;/p&gt;
&lt;p&gt;The fix sets `po-&amp;gt;num` to zero in `packet_release` while `bind_lock` is
held to prevent NETDEV_UP from linking, preventing the race window.&lt;/p&gt;
&lt;p&gt;This bug was found following an additional audit with Claude Code based
on CVE-2025-38617.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Linux, Siemens SIMATIC S7-1500 CPU 1518-4 PN/DP MFP, Siemens SIMATIC S7-1500 CPU 1518F-4 PN/DP MFP, Siemens SIPLUS S7-1500 CPU 1518-4 PN/DP MFP&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;net: fix fanout UAF in packet_release() via NETDEV_UP race&lt;/p&gt;
&lt;p&gt;`packet_release()` has a race window where `NETDEV_UP` can re-register a
socket into a fanout group&amp;#39;s `arr[]` array. The re-registration is not
cleaned up by `fanout_release()`, leaving a dangling pointer in the fanout
array.
`packet_release()` does NOT zero `po-&amp;gt;num` in its `bind_lock` section.
After releasing `bind_lock`, `po-&amp;gt;num` is still non-zero and `po-&amp;gt;ifindex`
still matches the bound device. A concurrent `packet_notifier(NETDEV_UP)`
that already found the socket in `sklist` can re-register the hook.
For fanout sockets, this re-registration calls `__fanout_link(sk, po)`
which adds the socket back into `f-&amp;gt;arr[]` and increments `f-&amp;gt;num_members`,
but does NOT increment `f-&amp;gt;sk_ref`.&lt;/p&gt;
&lt;p&gt;The fix sets `po-&amp;gt;num` to zero in `packet_release` while `bind_lock` is
held to prevent NETDEV_UP from linking, preventing the race window.&lt;/p&gt;
&lt;p&gt;This bug was found following an additional audit with Claude Code based
on CVE-2025-38617.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/cve-2026-31504</guid>
    </item>
  </channel>
</rss>
