CVE-2026-53259
Received Received - Intake
Use-After-Free in Linux Kernel IPv6 Anycast Handling

Publication date: 2026-06-25

Last updated on: 2026-06-25

Assigner: kernel.org

Description
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 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/[email protected]/
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-06-25
Last Modified
2026-06-25
Generated
2026-06-25
AI Q&A
2026-06-25
EPSS Evaluated
N/A
NVD
CVE-2026-53259
EUVD
EUVD-2026-39210
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
linux linux_kernel *
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN
Attack-Flow Graph
AI Quick Actions
Instant insights powered by AI
Mitigation Strategies

The vulnerability is resolved by moving the ipv6_add_acaddr_hash() call inside the idev->lock section to ensure atomic insertion and removal of the aca from the ac_list and hash, preventing use-after-free conditions.

Immediate mitigation steps would include updating the Linux kernel to a version that contains this fix, as the issue arises from a race condition in the kernel's IPv6 anycast address handling.

Executive Summary

This vulnerability is a use-after-free issue in the Linux kernel's IPv6 anycast address handling. Specifically, it occurs in the function ipv6_chk_acast_addr(), which accesses a global hash list of IPv6 anycast addresses. Due to a race condition between inserting an address into the hash and removing it during device teardown, a freed memory object (aca) can still be referenced by readers, leading to dereferencing of freed memory.

The problem arises because the insertion of the anycast address into the global hash happens after releasing a lock, while the removal can happen concurrently under another lock. This timing allows the address to be freed while still linked in the hash, causing later readers to access invalid memory.

The fix involved moving the insertion of the anycast address into the hash inside the lock section to make insertion and removal atomic, preventing the race condition.

Impact Analysis

This vulnerability can lead to a use-after-free condition, which may cause system instability, crashes (kernel panics), or potentially allow an attacker to execute arbitrary code or cause denial of service by exploiting the dangling pointer in the kernel's IPv6 anycast address handling.

Chat Assistant
Ask questions about this CVE
Hi! I’m here to help you understand CVE-2026-53259. Ask me anything about the vulnerability, its impact, or mitigation strategies.
0/70
EPSS Chart