Look up another CVE · open CVE-2025-22109 in the interactive tracker
CVE-2025-22109
ax25: Remove broken autobind
Published 2025-04-16 (18 months ago) by the Linux kernel CNA. Subsystem include/net. Debian urgency: not yet assigned.
What to do, per Debian release
Debian's own status for CVE-2025-22109 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | vulnerable | 6.1.190-1 | No fix published anywhere yet, neither in Debian nor upstream for the series bookworm tracks. Watch the Debian tracker page for this CVE. Advisories for bookworm have historically landed a median of 23 days after publication. |
| Debian 13trixie | vulnerable | 6.12.113-1 | No fix published anywhere yet, neither in Debian nor upstream for the series trixie tracks. Watch the Debian tracker page for this CVE. Advisories for trixie have historically landed a median of 11 days after publication. |
| Debian 14forky | fixed | 6.16.3-1 | Update the kernel and reboot. Fixed in 6.16.3-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 6.16.3-1 | Update the kernel and reboot. Fixed in 6.16.3-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
Binding AX25 socket by using the autobind feature leads to memory leaks in ax25_connect() and also refcount leaks in ax25_release(). Memory leak was detected with kmemleak: ================================================================ unreferenced object 0xffff8880253cd680 (size 96): backtrace: __kmalloc_node_track_caller_noprof (./include/linux/kmemleak.h:43) kmemdup_noprof (mm/util.c:136) ax25_rt_autobind (net/ax25/ax25_route.c:428) ax25_connect (net/ax25/af_ax25.c:1282) __sys_connect_file (net/socket.c:2045) __sys_connect (net/socket.c:2064) __x64_sys_connect (net/socket.c:2067) do_syscall_64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) ================================================================ When socket is bound, refcounts must be incremented the way it is done in ax25_bind() and ax25_setsockopt() (SO_BINDTODEVICE). In case of autobind, the refcounts are not incremented. This bug leads to the following issue reported by Syzkaller: ================================================================ ax25_connect(): syz-executor318 uses autobind, please contact jreuter@yaina.de ------------[ cut here ]------------ refcount_t: decrement hit 0; leaking memory. WARNING: CPU: 0 PID: 5317 at lib/refcount.c:31 refcount_warn_saturate+0xfa/0x1d0 lib/refcount.c:31 Modules linked in: CPU: 0 UID: 0 PID: 5317 Comm: syz-executor318 Not tainted 6.14.0-rc4-syzkaller-00278-gece144f151ac #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 RIP: 0010:refcount_warn_saturate+0xfa/0x1d0 lib/refcount.c:31 ... Call Trace: <TASK> __refcount_dec include/linux/refcount.h:336 [inline] refcount_dec include/linux/refcount.h:351 [inline] ref_tracker_free+0x6af/0x7e0 lib/ref_tracker.c:236 netdev_tracker_free include/linux/netdevice.h:4302 [inline] netdev_put include/linux/netdevice.h:4319 [inline] ax25_release+0x368/0x960 net/ax25/af_ax25.c:1080 __sock_release net/socket.c:647 [inline] sock_close+0xbc/0x240 net/socket.c:1398 __fput+0x3e9/0x9f0 fs/file_table.c:464 __do_sys_close fs/open.c:1580 [inline] __se_sys_close fs/open.c:1565 [inline] __x64_sys_close+0x7f/0x110 fs/open.c:1565 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f ... </TASK> ================================================================ Considering the issues above and the comments left in the code that say: "check if we can remove this feature. It is broken."; "autobinding in this may or may not work"; - it is better to completely remove this feature than to fix it because it is broken and leads to various kinds of memory bugs. Now calling connect() without first binding socket will result in an error (-EINVAL). Userspace software that relies on the autobind feature might get broken. However, this feature does not seem widely used with this specific driver as it was not reliable at any point of time, and it is already broken anyway. E.g. ax25-tools and ax25-apps packages for popular distributions do not use the autobind feature for AF_AX25. Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
include/net/ax25.h
net/ax25/af_ax25.c
net/ax25/ax25_route.c
- What this is
- NETWORKING [GENERAL]MAINTAINERS section matched on include/net/ · netdev@vger.kernel.org · Maintained
- Kernel module
- ax25
Check it on the machine
grep -w CONFIG_AX25 /boot/config-$(uname -r)Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.
lsmod | grep -w ax25Prints a line if that module is loaded right now, and nothing if it is not. One that is not loaded can still be loaded later by anything that needs it.
Show whether Debian builds this, per release
Debian builds this, but not on every flavour. At least one release below builds the code on some of its kernel flavours and not on others, so the answer depends on the architecture and flavour installed. The build rule could not be established for 2 releases, so nothing is claimed about those.
- bookworm, trixieMnot built on amd64/cloud-amd64, arm64/cloud-arm64
- forky, sid?
- M
- a module where it is built at all; some flavours do not build it
- ?
- not established - no Makefile entry for the affected file
Where a release above reads "not established", no build rule for the affected file was found in that release's kernel tree. That is a gap in this lookup, not a finding that the code is absent.
- Build switch
- CONFIG_AX25
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages
Signals
- Published
- 2025-04-16 (18 months ago)source
- CVSS
- 7.8 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.18%, higher than 7.1% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- Subsystem
- include/net
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 2.6.12 | 6.14.2 | 61203fdd3e35 |
| 2.6.12 | 6.15 | 2f6efbabceb6 |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:LAttack vector, local
- The vulnerability is triggered by a local `connect(2)` syscall on an AF_AX25 socket followed by `close(2)`; a remote packet-radio peer cannot drive the socket API. The freed object is subsequently consumed by the frame-receive path, but the trigger itself is local.
- AC:LAttack complexity, low
- A single deterministic connect()+close() sequence on an unbound AF_AX25 socket unbalances both refcounts — no race, no memory-layout dependency, and it can be repeated at will. On the realistic deployment for this subsystem (a configured AX.25 node with a port and route), the attacker triggers it reliably every time.
- PR:LPrivileges required, low
- `ax25_create()` requires no capability for SOCK_SEQPACKET/SOCK_DGRAM (only SOCK_RAW checks CAP_NET_RAW), and the autobind CAP_NET_BIND_SERVICE check is disabled by the default `ax25_uid_policy=0`, so any unprivileged local account suffices. The socket family also autoloads the module via MODULE_ALIAS_NETPROTO(PF_AX25).
- UI:NUser interaction, none
- The entire sequence is performed by the attacker's own process with no victim action required.
- S:UScope, unchanged
- The refcount underflow and resulting memory corruption stay within the kernel's own security authority; no VM, IOMMU, or sandbox boundary is crossed.
- C:HConfidentiality impact, high
- The premature `kfree_rcu()` of `ax25_dev` leaves a freed object still reachable for reads via `dev->ax25_ptr` in `ax25_rcv()`, via the `ax25_dev_list` walk, and — critically — via the world-readable `/proc/sys/net/ax25/<dev>/*` entries whose `.data` points into the freed slab, giving a direct read window onto whatever object is reallocated there.
- I:HIntegrity impact, high
- The same UAF is a write primitive: the registered sysctl table writes ints directly into the freed `ax25_dev->values[]`, and the RX path mutates the freed object, so heap spraying yields controlled corruption of an attacker-chosen replacement object; the additional `netdev_put()` underflow can free a still-registered `net_device`.
- A:HAvailability impact, high
- The unbalanced puts produce an immediate `refcount_warn_saturate()` WARN and a use-after-free that panics on the next received AX.25 frame, `bind()`, sysctl access, or DAMA timer fire; it is repeatable and also permanently corrupts the netdev refcount.