<?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 09:27:40 +0000</lastBuildDate>
    <item>
      <title>CVE-2024-40910 — ax25: Fix refcount imbalance on inbound connections</title>
      <link>https://vulnerability.circl.lu/vuln/cve-2024-40910</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;ax25: Fix refcount imbalance on inbound connections&lt;/p&gt;
&lt;p&gt;When releasing a socket in ax25_release(), we call netdev_put() to
decrease the refcount on the associated ax.25 device. However, the
execution path for accepting an incoming connection never calls
netdev_hold(). This imbalance leads to refcount errors, and ultimately
to kernel crashes.&lt;/p&gt;
&lt;p&gt;A typical call trace for the above situation will start with one of the
following errors:&lt;/p&gt;
&lt;p&gt;refcount_t: decrement hit 0; leaking memory.
    refcount_t: underflow; use-after-free.&lt;/p&gt;
&lt;p&gt;And will then have a trace like:&lt;/p&gt;
&lt;p&gt;Call Trace:
    &amp;lt;TASK&amp;gt;
    ? show_regs+0x64/0x70
    ? __warn+0x83/0x120
    ? refcount_warn_saturate+0xb2/0x100
    ? report_bug+0x158/0x190
    ? prb_read_valid+0x20/0x30
    ? handle_bug+0x3e/0x70
    ? exc_invalid_op+0x1c/0x70
    ? asm_exc_invalid_op+0x1f/0x30
    ? refcount_warn_saturate+0xb2/0x100
    ? refcount_warn_saturate+0xb2/0x100
    ax25_release+0x2ad/0x360
    __sock_release+0x35/0xa0
    sock_close+0x19/0x20
    [...]&lt;/p&gt;
&lt;p&gt;On reboot (or any attempt to remove the interface), the kernel gets
stuck in an infinite loop:&lt;/p&gt;
&lt;p&gt;unregister_netdevice: waiting for ax0 to become free. Usage count = 0&lt;/p&gt;
&lt;p&gt;This patch corrects these issues by ensuring that we call netdev_hold()
and ax25_dev_hold() for new connections in ax25_accept(). This makes the
logic leading to ax25_accept() match the logic for ax25_bind(): in both
cases we increment the refcount, which…&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;ax25: Fix refcount imbalance on inbound connections&lt;/p&gt;
&lt;p&gt;When releasing a socket in ax25_release(), we call netdev_put() to
decrease the refcount on the associated ax.25 device. However, the
execution path for accepting an incoming connection never calls
netdev_hold(). This imbalance leads to refcount errors, and ultimately
to kernel crashes.&lt;/p&gt;
&lt;p&gt;A typical call trace for the above situation will start with one of the
following errors:&lt;/p&gt;
&lt;p&gt;refcount_t: decrement hit 0; leaking memory.
    refcount_t: underflow; use-after-free.&lt;/p&gt;
&lt;p&gt;And will then have a trace like:&lt;/p&gt;
&lt;p&gt;Call Trace:
    &amp;lt;TASK&amp;gt;
    ? show_regs+0x64/0x70
    ? __warn+0x83/0x120
    ? refcount_warn_saturate+0xb2/0x100
    ? report_bug+0x158/0x190
    ? prb_read_valid+0x20/0x30
    ? handle_bug+0x3e/0x70
    ? exc_invalid_op+0x1c/0x70
    ? asm_exc_invalid_op+0x1f/0x30
    ? refcount_warn_saturate+0xb2/0x100
    ? refcount_warn_saturate+0xb2/0x100
    ax25_release+0x2ad/0x360
    __sock_release+0x35/0xa0
    sock_close+0x19/0x20
    [...]&lt;/p&gt;
&lt;p&gt;On reboot (or any attempt to remove the interface), the kernel gets
stuck in an infinite loop:&lt;/p&gt;
&lt;p&gt;unregister_netdevice: waiting for ax0 to become free. Usage count = 0&lt;/p&gt;
&lt;p&gt;This patch corrects these issues by ensuring that we call netdev_hold()
and ax25_dev_hold() for new connections in ax25_accept(). This makes the
logic leading to ax25_accept() match the logic for ax25_bind(): in both
cases we increment the refcount, which…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/cve-2024-40910</guid>
    </item>
  </channel>
</rss>
