CVE-2026-64123

What it actually does

This is a Linux kernel use-after-free in the HSR/PRP networking subsystem. HSR generic-netlink node-list and node-status operations traverse the HSR node database while holding an RCU read lock, but HSR link teardown can delete and immediately free the same node objects through the RTM_DELLINK path. A local attacker able to exercise HSR netlink operations and remove an HSR interface at the right time may cause a reader to dereference a freed struct hsr_node. Depending on kernel configuration, allocator behavior, and exploit reliability, this can lead to kernel memory corruption, local privilege escalation, information disclosure, or a kernel crash.

Why it matters to the business

Systems that load or use the Linux HSR networking feature may be exposed to local kernel compromise or denial of service. The practical risk is highest on hosts where untrusted local users, containers, or workloads can obtain network-administration capabilities or interact with HSR interfaces. There is no current CISA KEV listing, no known ransomware association, and the EPSS score is low, but the CVSS impact is high because successful exploitation can affect confidentiality, integrity, and availability of the host.

How an attack unfolds

An attacker first needs local access and sufficient privileges to interact with the relevant Linux networking interfaces, typically capabilities such as CAP_NET_ADMIN in the affected network namespace. The attacker creates or uses an HSR interface with populated node state, then repeatedly triggers generic-netlink HSR node-list or node-status queries while racing deletion of the HSR link through RTM_DELLINK. In the vulnerable kernel, the reader may retain a pointer to an HSR node after teardown has removed and freed it. The attacker attempts to widen and win this race so the kernel copies or reads fields from freed memory, such as the node MAC address. A basic exploit may only crash the kernel; a more advanced exploit may try to reclaim the freed slab object with attacker-controlled data to turn the use-after-free into privilege escalation or kernel memory disclosure.

How to fix it

Upgrade to a kernel version that includes the fix changing HSR node deletion to use RCU-safe deletion and deferred freeing via list_del_rcu() and hsr_free_node_rcu(). If vendor-specific fixed package versions are not yet available, apply the latest security kernel updates from the Linux distribution or kernel vendor and confirm the patch for the HSR node table lifetime issue is included. As interim mitigation, disable or avoid loading the HSR module where HSR/PRP networking is not required, restrict CAP_NET_ADMIN and privileged container use, prevent untrusted users from creating or deleting network interfaces, and limit access to systems where HSR interfaces are present. Reboot into the patched kernel after installation; merely installing a kernel package without booting it does not remediate the running kernel.

How to confirm the fix worked

Confirm the running kernel, not only the installed kernel package, contains the HSR RCU lifetime fix. Validate by checking the active kernel version with standard OS tooling and comparing it with the distribution vendor advisory or upstream stable release containing the patch. Where source or debuginfo is available, confirm the HSR teardown path uses list_del_rcu() and deferred freeing through call_rcu()/hsr_free_node_rcu() rather than immediate deletion and free. Also verify whether HSR is in use or loadable by checking for the hsr module and HSR interfaces. Exposure is materially reduced if the patched kernel is running, the hsr module is unavailable or disabled, and untrusted users/containers cannot obtain CAP_NET_ADMIN.

Typical attack path

1. Obtain local code execution on a Linux system running an affected kernel with the HSR networking code available.
2. Gain or abuse permission to manage network links in a network namespace, such as CAP_NET_ADMIN.
3. Create or identify an HSR interface and cause HSR node entries to exist in the node database.
4. Continuously issue HSR generic-netlink node-list or node-status requests that traverse the node database under RCU read lock.
5. Concurrently delete the HSR interface through RTM_DELLINK to trigger hsr_dellink() and hsr_del_nodes().
6. Race the reader so it dereferences a struct hsr_node that has already been freed.
7. Use the resulting memory corruption to crash the kernel or attempt local privilege escalation.

How to detect it

Retrospective detection is difficult because successful local kernel memory corruption may leave few durable artifacts beyond kernel logs or crash dumps. Review kernel logs, persistent journal entries, console logs, crash reports, and KASAN/KFENCE reports for use-after-free messages involving the HSR subsystem, especially functions such as hsr_get_next_node(), hsr_get_node_data(), hsr_dellink(), or hsr_del_nodes(). Look for unexpected kernel panics, general protection faults, page faults, BUG/Oops messages, or slab-use-after-free reports occurring near HSR interface deletion or RTM_DELLINK activity. If auditd or eBPF telemetry is available, review creation and deletion of HSR links, netlink activity from local processes, use of CAP_NET_ADMIN, and privileged container activity. Correlate suspicious local processes repeatedly invoking ip link operations or HSR netlink requests with kernel instability. Absence of these artifacts does not prove non-exploitation, especially on non-debug kernels without persistent logging.

• KASAN: slab-use-after-free
• BUG: KASAN: slab-use-after-free
• slab-use-after-free in hsr_get_node_data
• slab-use-after-free in hsr_get_next_node
• hsr_get_node_data
• hsr_get_next_node
• hsr_dellink
• hsr_del_nodes
• hsr_free_node_rcu
• RTM_DELLINK
• net: hsr
• type hsr
• ip link add type hsr
• ip link delete

What your security team should do

• Prioritize patching Linux hosts that use HSR/PRP networking, run privileged containers, provide shell access to untrusted users, or allow delegated network namespace administration.
• Deploy the latest vendor kernel security updates and reboot systems into the fixed kernel.
• Inventory systems with the HSR module loaded or HSR interfaces configured, and treat them as the highest-priority exposure set.
• Restrict CAP_NET_ADMIN, privileged containers, and network namespace creation to trusted administrative workloads only.
• If HSR is not operationally required, blacklist or disable the hsr kernel module as a temporary hardening measure.
• Monitor for kernel crashes, KASAN use-after-free reports, or suspicious bursts of HSR generic-netlink queries combined with network link deletion.
• Because exploit maturity is currently reported as none and EPSS is low, balance urgency against exposure, but do not defer patching on multi-user or container-hosting systems.