Look up another CVE · open CVE-2026-53259 in the interactive tracker
CVE-2026-53259
ipv6: anycast: insert aca into global hash under idev->lock
Published 2026-06-25 (4 months ago) by the Linux kernel CNA. Subsystem net/ipv6. Debian urgency: unimportant.
What to do, per Debian release
Debian's own status for CVE-2026-53259 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 | not affected | 6.1.190-1 | Nothing to do. bookworm never shipped the vulnerable code. |
| Debian 13trixie | not affected | 6.12.113-1 | Nothing to do. trixie never shipped the vulnerable code. |
| Debian 14forky | fixed | 7.0.13-1 | Update the kernel and reboot. Fixed in 7.0.13-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.0.13-1 | Update the kernel and reboot. Fixed in 7.0.13-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
syzbot reported a splat [1]: a slab-use-after-free in ipv6_chk_acast_addr(), which walks the global inet6_acaddr_lst[] hash under RCU and dereferences a struct ifacaddr6 that has already been freed while still linked in the hash, so a later reader walks into a dangling node. In __ipv6_dev_ac_inc() the aca is allocated with refcount 1, then aca_get() bumps it to 2 to keep it alive across the unlocked region. It is published to idev->ac_list under idev->lock, but ipv6_add_acaddr_hash() runs after write_unlock_bh(). A concurrent teardown (ipv6_ac_destroy_dev() from addrconf_ifdown(), under RTNL) can slip into that window: CPU0 __ipv6_dev_ac_inc CPU1 ipv6_ac_destroy_dev (RTNL) ------------------------------ ------------------------------------ aca_alloc() refcnt 1 aca_get() refcnt 2 write_lock_bh(idev->lock) add aca to ac_list write_unlock_bh(idev->lock) write_lock_bh(idev->lock) pull aca off ac_list write_unlock_bh(idev->lock) ipv6_del_acaddr_hash(aca) hlist_del_init_rcu() is a no-op, aca is not in the hash yet aca_put() refcnt 2->1 ipv6_add_acaddr_hash(aca) aca now inserted into the hash aca_put() refcnt 1->0 call_rcu(aca_free_rcu) -> kfree(aca) The hash removal becomes a no-op because the insertion has not happened yet, so once CPU0 inserts and drops the last reference, the aca is freed while still linked in inet6_acaddr_lst[], and readers dereference freed memory after the slab slot is reused. This window opened once RTNL stopped serializing the join path against device teardown. Move ipv6_add_acaddr_hash() inside the idev->lock section so the ac_list and hash insertions are atomic with respect to teardown: a racing remover now either misses the aca entirely or finds it in both lists. acaddr_hash_lock is now nested under idev->lock, which is acquired in softirq context, so switch all acaddr_hash_lock sites to spin_lock_bh() to avoid the irq lock inversion reported in [2]. [1] https://syzkaller.appspot.com/bug?extid=a01df04303c131efbf3a [2] https://lore.kernel.org/netdev/6a194ef7.ba3b1513.1890b4.0000.GAE@google.com/
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.
net/ipv6/anycast.c
- What this is
- NETWORKING [IPv4/IPv6]MAINTAINERS section matched on net/ipv6/anycast.c · netdev@vger.kernel.org · Maintained
Check it on the machine
grep -w CONFIG_IPV6 /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.
Show whether Debian builds this, per release
Debian builds this code. Every release below compiles the affected file into the kernels it ships.
- bookworm, trixie, forky, sidy
- y
- built into the kernel image on every flavour - only a patch removes it
- Build switch
- CONFIG_IPV6
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
- 2026-06-25 (4 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.11%, higher than 1.5% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- unimportantsource
- Subsystem
- net/ipv6
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 6.17 | 6.18.36 | 15be7e9fdbff |
| 6.17 | 7.0.13 | 3a967c498baa |
| 6.17 | 7.1 | f723ccaff2fb |
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 vulnerable anycast insertion path is reached through local IPv6 socket configuration such as setsockopt(IPV6_JOIN_ANYCAST), with teardown driven by local netdevice unregister/down paths. Remote packets can hit a later reader, but an attacker must first locally create the dangling anycast object.
- AC:LAttack complexity, low
- The bug is a race between anycast join and device teardown, and a local attacker with net namespace control can drive both sides concurrently and retry. No rare external condition is required beyond winning an attacker-created race.
- PR:LPrivileges required, low
- The join path checks CAP_NET_ADMIN in net->user_ns, which is reachable by an unprivileged user in a user/network namespace on systems permitting unprivileged user namespaces. It does not require real init-namespace root in the highest reasonable scenario.
- UI:NUser interaction, none
- Exploitation does not require a victim user to open a file, mount a filesystem, or perform any action. The attacker can invoke the socket option and teardown paths directly.
- S:UScope, unchanged
- The impact is within the kernel/network namespace security authority and does not cross a VM, IOMMU, or separate trust boundary. Kernel privilege escalation or kernel crash is scored as unchanged scope.
- C:HConfidentiality impact, high
- This is a slab use-after-free where a freed ifacaddr6 remains linked in the global anycast hash and later readers dereference reused heap contents including pointers. Per kernel UAF guidance and the dangling global pointer primitive, high confidentiality impact is appropriate.
- I:HIntegrity impact, high
- A kernel use-after-free with attacker-influenced heap reuse can potentially be shaped into memory corruption or control-flow/data corruption primitives. When uncertain for UAF exploitability, the higher severity integrity impact is selected.
- A:HAvailability impact, high
- syzbot reported a KASAN slab-use-after-free in ipv6_chk_acast_addr, and dereferencing the stale object can crash/oops the kernel. This is high availability impact.