CVE-2026-53259: ipv6: anycast: insert aca into global hash under idev->lock
In the Linux kernel, the following vulnerability has been resolved:
ipv6: anycast: insert aca into global hash under idev->lock
syzbot reported a splat [1]: a slab-use-after-free in ipv6chkacastaddr(), which walks the global inet6acaddrlst[] 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 ipv6devacinc() the aca is allocated with refcount 1, then acaget() bumps it to 2 to keep it alive across the unlocked region. It is published to idev->aclist under idev->lock, but ipv6addacaddrhash() runs after writeunlockbh(). A concurrent teardown (ipv6acdestroydev() from addrconfifdown(), under RTNL) can slip into that window:
CPU0 ipv6devacinc CPU1 ipv6acdestroydev (RTNL) ------------------------------ ------------------------------------ acaalloc() refcnt 1 acaget() refcnt 2 writelockbh(idev->lock) add aca to aclist writeunlockbh(idev->lock) writelockbh(idev->lock) pull aca off aclist writeunlockbh(idev->lock) ipv6delacaddrhash(aca) hlistdelinitrcu() is a no-op, aca is not in the hash yet acaput() refcnt 2->1 ipv6addacaddrhash(aca) aca now inserted into the hash acaput() refcnt 1->0 callrcu(acafreercu) -> 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 inet6acaddrlst[], 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 ipv6addacaddrhash() inside the idev->lock section so the aclist and hash insertions are atomic with respect to teardown: a racing remover now either misses the aca entirely or finds it in both lists.
acaddrhashlock is now nested under idev->lock, which is acquired in softirq context, so switch all acaddrhashlock sites to spinlockbh() 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/
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Update the Linux kernel IPv6 anycast implementation to move ipv6_add_acaddr_hash() inside idev->lock so insertion/removal in the global hash becomes atomic with respect to the protected lists and softirq context.
Linux kernel IPv6 anycast ipv6_add_acaddr_hash() locking/insertion ordering = Move ipv6_add_acaddr_hash() inside idev->lock - Configuration
Change all acaddr_hash_lock sites to use spin_lock_bh() (and corresponding bottom-half unlock where applicable) to avoid the irq lock inversion and ensure correct locking versus softirq context.
Linux kernel IPv6 anycast (acaddr_hash_lock) acaddr_hash_lock primitive (spin_lock_bh vs spin_lock) = Use spin_lock_bh() for all acaddr_hash_lock sites
Event History
Frequently Asked Questions
What is the severity of CVE-2026-53259?
CVE-2026-53259 has a CVSS risk score of 65.
What software is affected by CVE-2026-53259?
CVE-2026-53259 affects the Linux kernel.
What type of vulnerability is CVE-2026-53259?
CVE-2026-53259 is classified as a use-after-free vulnerability.
How do I fix CVE-2026-53259?
To fix CVE-2026-53259, you should update the Linux kernel to the latest version provided by your distribution.
What are the potential consequences of CVE-2026-53259?
Exploitation of CVE-2026-53259 could lead to undefined behavior in the Linux kernel, potentially allowing an attacker to execute arbitrary code.