CVE-2026-53259

What it actually does

This is a Linux kernel IPv6 anycast race condition that can leave a freed ifacaddr6 anycast-address object linked in the global IPv6 anycast hash table. A concurrent anycast address add path and network-device teardown path can interleave so removal does not see the object, insertion happens afterward, and the final reference is dropped, causing a use-after-free when later IPv6 anycast lookups walk the hash. The likely outcomes are kernel memory corruption, kernel crash/panic, and potentially local privilege escalation if an attacker can reliably shape allocation reuse after the freed object is referenced. Remote-only exploitation is not expected from the available description; practical exploitation would require the ability to manipulate local networking state, such as IPv6 addresses, interfaces, network namespaces, or privileged container networking.

Why it matters to the business

Affected Linux systems may be crashed or destabilized by a user or workload with sufficient network-administration capability, causing service interruption on hosts, appliances, or container nodes. Because the flaw is in kernel memory handling, a reliable exploit could potentially move beyond denial of service into host-level compromise, although there is currently no known public exploit, no CISA KEV listing, no ransomware association, and EPSS is very low. Organizations that allow untrusted users or containers to create network namespaces, manage IPv6 addresses, or hold CAP_NET_ADMIN should treat this as higher priority than general-purpose servers where only trusted administrators can change network configuration.

How an attack unfolds

An attacker first obtains local execution in a context that can change network configuration, such as a privileged container, a container with CAP_NET_ADMIN, a user namespace configuration that permits network namespace creation, or an already-privileged local account. They then repeatedly race IPv6 anycast address creation against interface or IPv6 device teardown. In the vulnerable kernel, the anycast object can be placed on the per-device list before it is inserted into the global anycast hash. If teardown occurs in that small window, the remover takes it off the device list, attempts hash removal before hash insertion has occurred, and drops a reference. The join path then inserts the object into the global hash and drops the final reference, freeing memory while the hash still points at it. Later IPv6 anycast lookups may dereference the dangling pointer. A basic exploit would aim to trigger a kernel crash; an advanced exploit would attempt heap grooming so the freed slab slot is reused with attacker-influenced data before dereference.

How to fix it

Update to a vendor kernel that includes the upstream fix moving ipv6_add_acaddr_hash() inside the idev->lock critical section and using bottom-half-safe locking for the anycast hash paths. No exact affected product list or fixed package versions were provided, so remediation should be tracked through the relevant Linux distribution, appliance, cloud image, or kernel vendor advisory for this vulnerability. Where immediate patching is not possible, reduce exposure by removing unnecessary CAP_NET_ADMIN from containers and services, disabling unprivileged user namespace creation where feasible, preventing untrusted users from creating network namespaces or virtual interfaces, and disabling IPv6 only where it is operationally safe and supported. Treat mitigation as risk reduction only; kernel update is the durable fix.

How to confirm the fix worked

Confirm the running kernel package or image is at or above the vendor-fixed version for this issue, not merely that a patched package is installed but not booted. Validate with the active kernel version from uname -a and the distribution package database or image manifest. Review vendor changelogs for references to IPv6 anycast, ifacaddr6, ipv6_add_acaddr_hash(), ipv6_chk_acast_addr(), or the relevant vulnerability identifier. In high-assurance environments, verify the patch by inspecting the kernel source or vendor backport to ensure IPv6 anycast hash insertion occurs while holding idev->lock. After remediation, reboot into the fixed kernel and confirm no older vulnerable kernels remain selected as the default boot entry.

Typical attack path

1. Gain local code execution on a Linux system or inside a container/workload with network-administration capability.
2. Ensure IPv6 and anycast address handling are available on an interface or network namespace.
3. Repeatedly add IPv6 anycast addresses while concurrently tearing down the related interface, IPv6 device state, or network namespace.
4. Win the race where the anycast object is removed before it is inserted into the global hash, then inserted and freed while still linked.
5. Trigger an IPv6 anycast lookup path such as ipv6_chk_acast_addr() to dereference the freed object.
6. Cause kernel panic/denial of service, or attempt heap grooming for controlled memory corruption and possible privilege escalation.

How to detect it

Retrospective detection should focus on signs of kernel memory corruption or crashes around IPv6 anycast handling and evidence that a local actor or workload was rapidly modifying network configuration. Review kernel logs from journalctl -k, dmesg archives, /var/log/kern.log, /var/log/messages, crash dumps, kdump/vmcore data, and hypervisor or cloud instance reset events. Look for KASAN, slab-use-after-free, general protection fault, BUG/Oops, panic, or RCU callback traces involving ipv6_chk_acast_addr(), ifacaddr6, ipv6_add_acaddr_hash(), ipv6_del_acaddr_hash(), __ipv6_dev_ac_inc(), ipv6_ac_destroy_dev(), addrconf_ifdown(), or aca_free_rcu(). Correlate crashes with auditd, shell history, EDR telemetry, container runtime logs, and orchestration events showing creation/deletion of network namespaces or interfaces, use of ip commands adding IPv6 anycast addresses, or workloads running with CAP_NET_ADMIN. Absence of these artifacts does not prove non-exploitation because a successful privilege-escalation attempt may leave few specific indicators beyond abnormal kernel behavior.

• BUG: KASAN: slab-use-after-free
• slab-use-after-free in ipv6_chk_acast_addr
• RIP: ipv6_chk_acast_addr
• ipv6_chk_acast_addr
• __ipv6_dev_ac_inc
• ipv6_ac_destroy_dev
• ipv6_add_acaddr_hash
• ipv6_del_acaddr_hash
• addrconf_ifdown
• aca_free_rcu
• ifacaddr6
• general protection fault
• kernel BUG at net/ipv6
• ip -6 addr add anycast
• CAP_NET_ADMIN

What your security team should do

• Prioritize patching systems where untrusted workloads, containers, CI jobs, or users can obtain CAP_NET_ADMIN, create network namespaces, or manipulate IPv6 interfaces.
• Inventory Linux kernels across servers, container hosts, appliances, and VM images; map them to vendor advisories and fixed kernel builds for this issue.
• Remove CAP_NET_ADMIN from containers and services unless strictly required, and enforce this through container runtime, Kubernetes Pod Security, admission control, or equivalent policy.
• Disable or restrict unprivileged user namespaces where feasible, especially on multi-tenant Linux hosts.
• Monitor for kernel crashes or KASAN reports involving ipv6_chk_acast_addr, ifacaddr6, ipv6_add_acaddr_hash, or IPv6 anycast address handling.
• For systems that cannot be patched quickly, consider disabling IPv6 only after confirming business and platform compatibility.
• Because this is not currently KEV-listed, has no known ransomware association, and has very low EPSS, prioritize based on local privilege boundaries and exposure rather than internet-facing status alone.