HIGH 7.8

CVE-2026-53259: Linux Kernel IPv6 Anycast Use-After-Free Vulnerability

A use-after-free vulnerability exists in the Linux kernel's IPv6 anycast address handling. When adding IPv6 anycast addresses, a race condition allows the kernel to insert an address into a global hash table after a concurrent teardown process has already removed it from the per-device list and released it. This creates a window where freed memory remains linked in the hash, and subsequent readers encounter dangling pointers. The vulnerability requires local access and can lead to kernel crashes or privilege escalation. The fix moves hash insertion inside the lock-protected section to ensure atomicity with device teardown operations.

Source data · NVD / CISA · public domain

CVSS
3.1 · 7.8 HIGH · CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Weaknesses (CWE)
CWE-416
Affected products
7 configuration(s)
Published / Modified
2026-06-25 / 2026-07-08

NVD description (verbatim)

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]/

3 reference(s) · View on NVD →

SEC.co analysis · AI-assisted, reviewed against source

Technical summary

The vulnerability (CWE-416: Use After Free) occurs in IPv6 anycast address management within the Linux kernel. In __ipv6_dev_ac_inc(), an anycast address (aca) structure is allocated and added to a per-device list (idev->ac_list) under the device lock. However, ipv6_add_acaddr_hash() runs after the lock is released, creating a race window. Concurrently, ipv6_ac_destroy_dev() (invoked during device teardown under RTNL) can remove the address from the per-device list and release its reference before the hash insertion completes. Since hash removal is a no-op when the address was never inserted, the structure is freed while still linked in inet6_acaddr_lst[]. Subsequent RCU readers of the hash table dereference freed memory. The patch moves ipv6_add_acaddr_hash() inside the idev->lock critical section and switches acaddr_hash_lock to spin_lock_bh() to maintain proper lock ordering and prevent interrupt inversion.

Business impact

This vulnerability can cause unplanned kernel crashes on systems hosting IPv6 applications, particularly those performing frequent IPv6 anycast join/leave operations during interface reconfigurations. Affected systems may experience availability disruptions, unexpected reboots, or information disclosure if attackers craft specific workloads to trigger the race. Organizations running custom IPv6 applications or load-balanced services that manage IPv6 anycast addresses are at higher risk of impact.

Affected systems

All Linux kernel versions are affected. The vulnerability resides in core IPv6 network stack code present across all maintained kernel branches. Any Linux distribution using the affected code is vulnerable if the system supports IPv6 and allows local users to trigger IPv6 anycast operations.

Exploitability

The vulnerability requires local code execution (privilege level: low) on the affected system. An attacker with local user access can trigger the race condition by rapidly joining and leaving IPv6 anycast groups while inducing interface reconfigurations. The race window is narrow but reliably exploitable through concurrently running operations. No network access or special privileges are required beyond local execution capability. The CVSS 3.1 score of 7.8 (HIGH) reflects local attack vector, low privileges needed, and direct impact on confidentiality, integrity, and availability.

Remediation

Apply the kernel patch that relocates ipv6_add_acaddr_hash() into the idev->lock protected section and converts all acaddr_hash_lock operations to use spin_lock_bh(). This ensures atomic insertion into both the per-device list and global hash table with respect to concurrent teardown. Verify against vendor advisories for the specific kernel version deployed in your environment to identify the exact patch or kernel version that includes this fix.

Patch guidance

Identify your current kernel version using 'uname -r' and check the Linux kernel security advisory database for the specific fix commit or patched release version applicable to your branch (stable, longterm, etc.). The resolution involves moving hash insertion under lock protection; patch application should be validated through testing IPv6 anycast operations under load before production deployment. Prioritize kernel updates for systems actively using IPv6 features.

Detection guidance

Monitor system logs for kernel panics (Oops, BUG_ON, or KASAN messages) mentioning 'inet6_acaddr_lst', 'ipv6_chk_acast_addr', or 'use-after-free' in stack traces. Enable kernel Address Sanitizer (KASAN) on non-production systems to detect memory safety issues early. Track IPv6 interface state changes and anycast group memberships in environments under active development or testing. Network telemetry showing unexpected interface resets or IPv6 traffic disruptions may correlate with exploitation attempts.

Why prioritize this

This is a HIGH-severity local privilege escalation and denial of service vector affecting all Linux systems. While it requires local access, the simplicity of triggering the race (IPv6 operations + interface reconfigurations) and the potential for kernel crash or information disclosure make it a priority for patching in production environments, especially those running custom IPv6 applications or multi-tenant systems.

Risk score, explained

CVSS 3.1 score of 7.8 reflects: local attack vector (AV:L), low attack complexity (AC:L), low privilege requirements (PR:L), no user interaction needed (UI:N), high impact across confidentiality (C:H), integrity (I:H), and availability (A:H). The score appropriately captures the ease of triggering kernel memory corruption once local access is obtained, offsetting the local-only attack surface.

Frequently asked questions

Does this vulnerability require root or administrator privileges to exploit?

No. The vulnerability requires only low privilege level (a regular local user), though the attacker must have the ability to execute code on the affected system and trigger IPv6 anycast operations (such as joining multicast groups or reconfiguring network interfaces).

Can this vulnerability be exploited remotely over the network?

No. The attack vector is strictly local (AV:L per CVSS). The race condition is triggered by operations on the local system; remote network activity alone cannot exploit it.

What systems are most at risk?

Systems running containerized workloads with IPv6 enabled, multi-tenant cloud environments, and systems with custom IPv6 networking applications that frequently modify anycast group memberships or trigger interface reconfigurations. Standard servers with static IPv6 configurations face lower risk.

Will applying this patch cause downtime or require special configuration changes?

The patch modifies kernel-internal locking behavior without changing the IPv6 API or requiring configuration changes. Deployment requires a kernel reboot but does not necessitate network reconfiguration or application modifications. Verify compatibility with your specific kernel branch before rolling out.

This analysis is based on publicly disclosed vulnerability information and kernel source code review. The CVSS score, affected versions, and patch availability are provided as ground truth and should be verified against official Linux kernel security advisories and your vendor's documentation. No exploit code or weaponized proof-of-concept is provided. Organizations should evaluate their specific kernel versions and deployment scenarios to determine exposure and prioritize patching accordingly. Source: NVD (public-domain), retrieved 2026-08-03. Analysis generated by SEC.co (claude-haiku-4-5).