CVE-2026-64189

What it actually does

This is a Linux kernel use-after-free race in the netfilter ipset subsystem. The vulnerable path occurs when an ipset dump operation reads the ip_set_list array through netlink while a concurrent ip_set_create() operation resizes that same array. Because the dump path reads the pointer without holding the correct RCU read-side protection, the old array can be freed while still being accessed. The most direct technical result is kernel memory corruption and a kernel crash/panic. As with many kernel use-after-free flaws, exploitation impact depends heavily on kernel configuration, heap state, namespaces, capabilities, and hardening features; practical outcomes may range from local denial of service to potentially stronger kernel-level compromise if an attacker can reliably shape memory reuse.

Why it matters to the business

Systems that allow local users, containers, or privileged network-management components to manipulate ipset/netfilter state may be vulnerable to host instability. Successful triggering can crash the kernel, interrupt network filtering, terminate workloads, and cause service outages. The vulnerability is not currently listed in CISA KEV, has no reported ransomware association, and has a low EPSS score, which suggests no broad public exploitation signal at this time; however, because it affects kernel code, organizations should still prioritize remediation on multi-user Linux hosts, container platforms, edge systems, firewalls, routers, and infrastructure where ipset is used for packet filtering or service protection.

How an attack unfolds

An attacker first needs the ability to interact with the kernel netfilter/ipset control plane, typically through netlink interfaces used by ipset tooling or equivalent programmatic calls. The attacker then runs concurrent operations: one thread or process repeatedly starts ipset dump/list operations, while another creates enough ipsets to force the kernel to resize the internal ip_set_list array. During the race window, the dump path can retain and index a pointer to the old array after the create path has published a new array, waited with synchronize_net(), and freed the old one. If the timing is successful, the kernel reads freed memory in ip_set_dump_do() or related dump cleanup code. In observed failure mode this produces KASAN use-after-free reports, general protection faults, and kernel panic, resulting in denial of service. More advanced exploitation would attempt to control freed memory reuse before the stale read, but no mature public exploitation is indicated by the provided intelligence.

How to fix it

Apply the vendor kernel update that includes the netfilter ipset fix adding the required RCU read-side protection around the ip_set_list access in the dump paths. Because no exact fixed package versions were provided, track the relevant Linux distribution advisories and upgrade to the first fixed kernel release or later for each supported distribution and kernel stream. Reboot into the fixed kernel after installation; merely installing kernel packages is not sufficient if the running kernel remains vulnerable. Where immediate patching is not possible, reduce exposure by limiting who can obtain network administration privileges, avoiding unnecessary privileged containers, restricting CAP_NET_ADMIN assignment, disabling unneeded user namespaces where operationally feasible, and limiting access to ipset/netfilter management tooling to trusted administrators. Mitigations reduce exploitability but do not replace the kernel fix.

How to confirm the fix worked

Confirm the running kernel, not only the installed package, is updated to a vendor release containing the ipset race fix. Validate with uname -r, package-manager metadata, and the distribution security advisory for the deployed kernel stream. If source-based validation is possible, confirm the ipset dump release paths protect the ip_set_list dereference with rcu_read_lock()/rcu_read_unlock() or an equivalent upstream backport. Check whether ipset functionality is present and in use by reviewing loaded modules and rulesets, such as lsmod output for ip_set-related modules and ipset list behavior. After remediation, reboot and verify no vulnerable kernel remains selected in the bootloader. For high-assurance validation in test environments, run controlled ipset dump/create concurrency tests only on non-production systems and confirm the kernel no longer emits KASAN, general protection fault, or panic messages in the affected code paths.

Typical attack path

1. Obtain local execution in a context allowed to manage netfilter/ipset state, such as a privileged user, container with relevant network administration capabilities, or network-management component.
2. Open netlink communication with the kernel netfilter/ipset subsystem or invoke ipset-compatible tooling.
3. Continuously trigger ipset dump/list operations that enter ip_set_dump_do() or ip_set_dump_done().
4. Concurrently create ipsets to force ip_set_list growth and replacement through ip_set_create().
5. Win the race so the dump path indexes the old ip_set_list array after it has been freed.
6. Cause kernel memory corruption, commonly producing a general protection fault or kernel panic and service outage.

How to detect it

Look for evidence of kernel crashes, KASAN reports, or general protection faults involving the netfilter ipset code path. Primary log sources include journald, dmesg, /var/log/kern.log, /var/log/messages, /var/log/syslog, kernel crash dumps, kdump/vmcore artifacts, auditd logs, shell history, sudo logs, and container runtime or orchestration audit logs showing privileged workloads manipulating ipset. Search for concurrent or repeated ipset create/list/save/dump activity immediately before a kernel oops or reboot. On container platforms, review events for containers granted CAP_NET_ADMIN, privileged mode, host networking, or host namespace access shortly before the crash. Because this issue may manifest only as a panic, absence of application-layer indicators does not rule out exploitation. Treat unexplained kernel panics with ip_set_dump_do(), ip_set_dump_done(), netlink_dump(), or netlink_recvmsg() in the stack trace as high-value leads.

• KASAN: slab-use-after-free in ip_set_dump_do
• BUG: KASAN: slab-use-after-free
• ip_set_dump_do
• ip_set_dump_done
• ip_set_create
• netfilter: ipset
• net/netfilter/ipset/ip_set_core.c
• netlink_dump
• netlink_recvmsg
• Kernel panic - not syncing: Fatal exception
• general protection fault, probably for non-canonical address
• KASAN: maybe wild-memory-access
• RIP: 0010:ip_set_dump_do
• ipset create
• ipset list
• ipset save

What your security team should do

• Inventory Linux systems that use netfilter/ipset, especially firewalls, Kubernetes/container hosts, VPN gateways, routers, load balancers, and multi-user servers.
• Prioritize patching systems where untrusted users or workloads may gain CAP_NET_ADMIN or equivalent netfilter management access.
• Upgrade to the vendor-fixed kernel release and reboot systems to ensure the fixed kernel is active.
• Audit privileged containers and remove unnecessary CAP_NET_ADMIN, hostNetwork, or broad host namespace access.
• Restrict ipset/netfilter administration to trusted operators and automation accounts only.
• Monitor kernel logs for ip_set_dump_do, ip_set_dump_done, KASAN use-after-free, general protection fault, and unexpected kernel panic events.
• Review recent crashes or reboots on systems using ipset to determine whether they align with this failure signature.
• If exploitation is suspected, preserve kernel logs, crash dumps, audit logs, container runtime events, and command history before rebuilding or rebooting further.