CVE-2026-64563

What it actually does

This is a Linux kernel use-after-free in the rhashtable iterator restart logic. During certain multi-fragment hash table walks, rhashtable_walk_start_check() can resume after a table resize/free path without clearing a stale iterator pointer. rhashtable_walk_next() can then dereference memory that has already been freed. Known affected call paths include netlink diagnostic dumping and TIPC socket walking. The most likely technical outcome is a kernel crash or denial of service, though use-after-free bugs in kernel memory handling can sometimes create broader memory corruption risk depending on allocator state, kernel configuration, and reachable primitives.

Why it matters to the business

Successful exploitation can destabilize or crash Linux systems, interrupting workloads, network services, containers, and infrastructure components that depend on the affected kernel. Because the flaw is in common kernel infrastructure, exposure may exist across multiple Linux distributions once they ship affected kernel versions, even though no CISA KEV listing, ransomware use, or public exploit maturity is currently reported. The low EPSS score indicates limited observed exploitation likelihood at this time, but kernel denial-of-service flaws should still be prioritized on internet-facing, multi-tenant, container-hosting, or high-availability systems.

How an attack unfolds

An attacker needs a way to exercise kernel interfaces that perform multi-part rhashtable walks across walk_stop/walk_start boundaries. Practical trigger paths described for this issue include netlink_diag dumping and TIPC socket enumeration. The attacker repeatedly initiates diagnostic or socket-walk operations while creating conditions that cause the underlying rhashtable to resize or be freed between walk fragments. On the affected restart path, the iterator retains a stale pointer to a freed object. When the walk resumes, rhashtable_walk_next() dereferences that stale pointer, causing a slab use-after-free read. In typical exploitation, this results in a kernel oops, panic, or service-impacting crash. More advanced exploitation would require shaping kernel heap state and bypassing kernel hardening, and no mature public exploitation has been reported from the supplied data.

How to fix it

Apply vendor kernel updates that include the upstream fix for clearing stale iterator state on the rhashtable restart path. If exact fixed package versions are not yet available from the operating system vendor, track the distribution’s security advisory for this CVE and update to the first kernel release containing the fix. Reboot systems into the patched kernel after installation; merely installing a kernel package is not sufficient if the running kernel remains vulnerable. As interim risk reduction, restrict local shell/container access to trusted users, limit unprivileged container workloads where possible, disable or avoid loading TIPC if not required, and apply kernel hardening controls that reduce unprivileged access to diagnostic network interfaces where operationally feasible.

How to confirm the fix worked

Confirm the running kernel, not only the installed kernel package, has been updated to a vendor build containing the rhashtable iterator fix. Validate with standard platform commands such as uname -a, package-manager kernel version queries, and vendor advisory mapping. Review boot state to ensure hosts have rebooted into the patched kernel. Where feasible in a test environment, run vendor or regression tests that exercise netlink diagnostic dumps and TIPC socket enumeration without kernel warnings, KASAN findings, oopses, or panics. For exposure validation, inventory systems with affected kernel versions and check whether TIPC is enabled or loaded, and whether untrusted local users or containers can access the relevant kernel interfaces.

Typical attack path

1. Identify a Linux system running an affected kernel build with reachable netlink diagnostic or TIPC-related functionality.
2. Gain local code execution, container-level execution with sufficient kernel interface access, or another foothold that can issue the relevant socket/netlink operations.
3. Trigger repeated multi-fragment rhashtable walks, such as through netlink diagnostic dumps or TIPC socket walking.
4. Induce or race a table resize/free condition while the iterator is stopped and restarted.
5. Cause the restarted iterator to retain and dereference a stale freed pointer in rhashtable_walk_next().
6. Observe kernel instability, oops, panic, or denial of service; in more complex scenarios, attempt to use the memory corruption primitive for further impact.

How to detect it

Look for evidence of kernel crashes, oopses, KASAN reports, or unexplained reboots involving rhashtable_walk_next, rhashtable_walk_start_check, netlink diagnostic dumping, or TIPC socket walking. Relevant sources include journald, syslog, kern.log, dmesg snapshots, crash dump infrastructure, hypervisor reset events, endpoint telemetry, and container host monitoring. Search for slab-use-after-free reports that mention lib/rhashtable.c, net/netlink/diag.c, or net/tipc/socket.c. Correlate crashes with local users, containers, or processes issuing high volumes of netlink socket diagnostic requests or interacting with TIPC. Since exploitation is expected to be local or from code already running on the host, authentication logs, container runtime events, process accounting, auditd syscall records, and EDR telemetry around suspicious local enumeration activity may help identify the triggering principal. Absence of these strings does not prove non-exploitation, especially on systems without persistent kernel logging or crash dump retention.

• BUG: KASAN: slab-use-after-free in rhashtable_walk_next
• slab-use-after-free in rhashtable_walk_next
• rhashtable_walk_next+0x365/0x3c0
• rhashtable_walk_next
• rhashtable_walk_start_check
• lib/rhashtable.c:1016
• __netlink_diag_dump
• net/netlink/diag.c:122
• netlink_diag_dump
• netlink_dump
• netlink_recvmsg
• tipc_nl_sk_walk
• net/tipc/socket.c
• Read of size 8 at addr
• freed kmalloc-2k
• KASAN: slab-use-after-free
• BUG: kernel NULL pointer dereference
• kernel BUG at lib/rhashtable.c
• Oops:
• Kernel panic - not syncing

What your security team should do

• Inventory Linux systems by running kernel version and map them to vendor advisories for this vulnerability.
• Prioritize patching and rebooting multi-tenant systems, container hosts, critical network infrastructure, and high-availability servers.
• Monitor distribution advisories for exact fixed kernel package versions and deploy the first fixed release available for each platform.
• Temporarily reduce exposure by restricting untrusted local execution and disabling TIPC where it is not needed.
• Review kernel logs and crash telemetry for rhashtable, netlink_diag, TIPC, KASAN, oops, or panic signatures that match this issue.
• Ensure crash dumps are preserved for forensic review on critical systems until patched.
• Because no KEV listing, ransomware association, or mature exploit is reported, treat this as important but generally below actively exploited remote-code-execution issues unless local multi-tenant exposure is high.