CVE-2026-64002

What it actually does

This is a local Linux kernel use-after-free in IPv4 network namespace cleanup. The kernel frees net->ipv4.sysctl_local_reserved_ports before unregistering the related sysctl table, leaving a race window where another thread can still access /proc/sys/net/ipv4/ip_local_reserved_ports after the backing memory has been released. A local user or process able to exercise network namespace lifecycle and sysctl access could potentially trigger kernel memory corruption, leading to privilege escalation, information disclosure, or kernel crash.

Why it matters to the business

Systems running affected Linux kernels may be exposed to local privilege escalation or denial of service, especially multi-user hosts, container platforms, CI runners, shared development systems, and environments allowing unprivileged namespace creation. The current exploitation signal is low: EPSS is 0.00129, there is no known CISA KEV listing, no ransomware association, and no public exploit maturity is reported, but the CVSS impact is high because successful exploitation could give an attacker control over the host kernel.

How an attack unfolds

An attacker first needs local code execution with low privileges, such as a shell account, compromised application process, or code running inside a container where namespace operations are permitted. The attacker then attempts to create and tear down network namespaces while concurrently accessing the IPv4 sysctl entry /proc/sys/net/ipv4/ip_local_reserved_ports. Because the vulnerable cleanup path frees the local_reserved_ports storage before unregistering the sysctl table, a racing thread may dereference freed memory through the still-registered sysctl interface. With reliable heap grooming and timing, this condition could be developed from a crash into kernel memory corruption and potentially local privilege escalation; without reliable exploitation, it is more likely to appear as kernel oops, panic, or container/host instability.

How to fix it

Upgrade to a Linux kernel or vendor kernel package that includes the fix changing the cleanup order so net->ipv4.sysctl_local_reserved_ports is freed only after unregister_net_sysctl_table() completes. Because no exact fixed package versions were provided, follow the relevant distribution or appliance vendor advisory for CVE-2026-64002 and apply the first kernel release containing the upstream ipv4 sysctl cleanup fix. Reboot after installing the fixed kernel to ensure the vulnerable kernel is no longer running. If immediate patching is not possible, reduce exposure by disabling or restricting unprivileged user namespaces where operationally feasible, limiting container privileges, preventing unnecessary CAP_SYS_ADMIN/CAP_NET_ADMIN grants, restricting local shell access, and monitoring for abnormal namespace churn or kernel crashes.

How to confirm the fix worked

Confirm the running kernel, not just the installed package, has been updated by checking uname -r and the distribution package metadata after reboot. Validate against the vendor advisory or kernel changelog for the fix that frees net->ipv4.sysctl_local_reserved_ports after unregister_net_sysctl_table(). On source-built kernels, confirm the IPv4 network namespace teardown code in ipv4_sysctl_exit_net() unregisters the sysctl table before freeing sysctl_local_reserved_ports. Assess exposure by checking whether unprivileged users or containers can create network namespaces. Review recent kernel logs for oops, panic, or KASAN reports involving ip_local_reserved_ports, sysctl_local_reserved_ports, ipv4_sysctl_exit_net, or unregister_net_sysctl_table.

Typical attack path

1. Obtain local low-privileged execution on a Linux host or inside a container with sufficient namespace capabilities.
2. Determine that the kernel permits network namespace creation or that the process can interact with relevant network namespace lifecycle events.
3. Repeatedly create and destroy IPv4 network namespaces to drive ipv4_sysctl_exit_net() cleanup.
4. Concurrently read or write /proc/sys/net/ipv4/ip_local_reserved_ports from another thread or process during namespace teardown.
5. Trigger a use-after-free access through the sysctl table after net->ipv4.sysctl_local_reserved_ports has been freed.
6. Use the resulting memory corruption to crash the kernel or, with additional exploit engineering, attempt privilege escalation to kernel/root level.

How to detect it

There is no reliable remote network indicator for this vulnerability because exploitation requires local interaction with kernel namespace and sysctl behavior. To investigate possible prior exploitation, review kernel logs, system journal, crash dumps, and KASAN or kdump artifacts for use-after-free, kernel oops, panic, slab corruption, or general protection fault messages referencing IPv4 sysctl cleanup, ip_local_reserved_ports, sysctl_local_reserved_ports, ipv4_sysctl_exit_net, or unregister_net_sysctl_table. Correlate suspicious kernel faults with auditd, process accounting, EDR, or container runtime logs showing high-frequency unshare, clone, setns, nsenter, or container start/stop activity involving network namespaces. Look for low-privileged processes repeatedly reading or writing /proc/sys/net/ipv4/ip_local_reserved_ports while creating or destroying namespaces. Absence of these artifacts does not prove non-exploitation because a successful privilege escalation may leave minimal logs unless kernel diagnostics or syscall auditing were enabled.

• /proc/sys/net/ipv4/ip_local_reserved_ports
• ipv4_sysctl_exit_net
• sysctl_local_reserved_ports
• unregister_net_sysctl_table
• KASAN: use-after-free
• BUG: KASAN
• use-after-free in ipv4_sysctl_exit_net
• general protection fault
• kernel BUG
• kernel panic
• Oops:
• CLONE_NEWNET
• unshare -n
• nsenter --net
• setns

What your security team should do

• Prioritize patching shared Linux hosts, container hosts, CI/CD runners, bastion systems, and multi-tenant platforms before single-user workstations.
• Reboot systems after kernel package installation and verify the running kernel version is the fixed version.
• Temporarily restrict unprivileged user namespace and network namespace creation if patching cannot be completed quickly.
• Review container runtime and orchestration policies for excessive privileges such as host networking, CAP_SYS_ADMIN, CAP_NET_ADMIN, or unrestricted namespace creation.
• Monitor kernel logs for use-after-free, KASAN, oops, panic, or general protection fault messages involving IPv4 sysctl cleanup or ip_local_reserved_ports.
• Because EPSS is low, there is no KEV listing, and exploit maturity is currently none, treat this as important hardening rather than an active mass-exploitation emergency unless local compromise is already suspected.