<?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>Thu, 01 Oct 2026 07:50:09 +0000</lastBuildDate>
    <item>
      <title>CVE-2024-53212 — netlink: fix false positive warning in extack during dumps</title>
      <link>https://vulnerability.circl.lu/vuln/cve-2024-53212</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Linux&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;netlink: fix false positive warning in extack during dumps&lt;/p&gt;
&lt;p&gt;Commit under fixes extended extack reporting to dumps.
It works under normal conditions, because extack errors are
usually reported during -&amp;gt;start() or the first -&amp;gt;dump(),
it&amp;#39;s quite rare that the dump starts okay but fails later.
If the dump does fail later, however, the input skb will
already have the initiating message pulled, so checking
if bad attr falls within skb-&amp;gt;data will fail.&lt;/p&gt;
&lt;p&gt;Switch the check to using nlh, which is always valid.&lt;/p&gt;
&lt;p&gt;syzbot found a way to hit that scenario by filling up
the receive queue. In this case we initiate a dump
but don&amp;#39;t call -&amp;gt;dump() until there is read space for
an skb.&lt;/p&gt;
&lt;p&gt;WARNING: CPU: 1 PID: 5845 at net/netlink/af_netlink.c:2210 netlink_ack_tlv_fill+0x1a8/0x560 net/netlink/af_netlink.c:2209
RIP: 0010:netlink_ack_tlv_fill+0x1a8/0x560 net/netlink/af_netlink.c:2209
Call Trace:
 &amp;lt;TASK&amp;gt;
 netlink_dump_done+0x513/0x970 net/netlink/af_netlink.c:2250
 netlink_dump+0x91f/0xe10 net/netlink/af_netlink.c:2351
 netlink_recvmsg+0x6bb/0x11d0 net/netlink/af_netlink.c:1983
 sock_recvmsg_nosec net/socket.c:1051 [inline]
 sock_recvmsg+0x22f/0x280 net/socket.c:1073
 __sys_recvfrom+0x246/0x3d0 net/socket.c:2267
 __do_sys_recvfrom net/socket.c:2285 [inline]
 __se_sys_recvfrom net/socket.c:2281 [inline]
 __x64_sys_recvfrom+0xde/0x100 net/socket.c:2281
 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
 do_syscall_64+0xf3/0x230 arch/x86…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Linux&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;netlink: fix false positive warning in extack during dumps&lt;/p&gt;
&lt;p&gt;Commit under fixes extended extack reporting to dumps.
It works under normal conditions, because extack errors are
usually reported during -&amp;gt;start() or the first -&amp;gt;dump(),
it&amp;#39;s quite rare that the dump starts okay but fails later.
If the dump does fail later, however, the input skb will
already have the initiating message pulled, so checking
if bad attr falls within skb-&amp;gt;data will fail.&lt;/p&gt;
&lt;p&gt;Switch the check to using nlh, which is always valid.&lt;/p&gt;
&lt;p&gt;syzbot found a way to hit that scenario by filling up
the receive queue. In this case we initiate a dump
but don&amp;#39;t call -&amp;gt;dump() until there is read space for
an skb.&lt;/p&gt;
&lt;p&gt;WARNING: CPU: 1 PID: 5845 at net/netlink/af_netlink.c:2210 netlink_ack_tlv_fill+0x1a8/0x560 net/netlink/af_netlink.c:2209
RIP: 0010:netlink_ack_tlv_fill+0x1a8/0x560 net/netlink/af_netlink.c:2209
Call Trace:
 &amp;lt;TASK&amp;gt;
 netlink_dump_done+0x513/0x970 net/netlink/af_netlink.c:2250
 netlink_dump+0x91f/0xe10 net/netlink/af_netlink.c:2351
 netlink_recvmsg+0x6bb/0x11d0 net/netlink/af_netlink.c:1983
 sock_recvmsg_nosec net/socket.c:1051 [inline]
 sock_recvmsg+0x22f/0x280 net/socket.c:1073
 __sys_recvfrom+0x246/0x3d0 net/socket.c:2267
 __do_sys_recvfrom net/socket.c:2285 [inline]
 __se_sys_recvfrom net/socket.c:2281 [inline]
 __x64_sys_recvfrom+0xde/0x100 net/socket.c:2281
 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
 do_syscall_64+0xf3/0x230 arch/x86…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/cve-2024-53212</guid>
    </item>
  </channel>
</rss>
