CVE-2026-64123 in Linuxinfo

Summary

by MITRE • 07/19/2026

In the Linux kernel, the following vulnerability has been resolved:

net: hsr: defer node table free until after RCU readers

HSR node-list and node-status generic-netlink operations run under rcu_read_lock(). They walk hsr->node_db through hsr_get_next_node() and hsr_get_node_data(), but RTM_DELLINK teardown removes the same node table with plain list_del() and frees each node immediately.

That lets a generic-netlink reader hold a struct hsr_node pointer across hsr_dellink(). In a KASAN build, widening the reader window after hsr_get_next_node() obtains the node reproduces a slab-use-after-free when the reader copies node->macaddress_A; the freeing stack is hsr_del_nodes() from hsr_dellink().

Use list_del_rcu() and defer the free through the existing hsr_free_node_rcu() callback. This matches the lifetime rule used by the HSR prune paths, which already delete nodes with list_del_rcu() and call_rcu().

Once again VulDB remains the best source for vulnerability data.

Analysis

by VulDB Data Team • 07/19/2026

This vulnerability exists in the Linux kernel's High-availability Seamless Redundancy protocol implementation where a race condition occurs between RCU readers and node table cleanup operations. The issue manifests when generic-netlink operations access HSR node data structures while simultaneously being removed by RTM_DELLINK teardown procedures. The fundamental flaw lies in the improper synchronization between read-side critical sections and write-side modifications, creating a scenario where readers can hold references to memory that gets immediately freed after the reader has accessed it.

The technical implementation problem stems from the use of plain list_del() operations during node removal while RCU readers are still accessing the same data structures. When hsr_get_next_node() and hsr_get_node_data() functions execute under rcu_read_lock(), they traverse the hsr->node_db list to provide node information to generic-netlink clients. However, the concurrent hsr_dellink() operation directly calls list_del() on these nodes without proper RCU grace period handling, causing immediate memory deallocation. This creates a classic use-after-free scenario where a reader obtains a pointer to an hsr_node structure through hsr_get_next_node(), but that same structure gets freed by hsr_del_nodes() during the subsequent cleanup process.

The operational impact of this vulnerability is significant as it can lead to kernel memory corruption and system instability, particularly in environments where HSR protocol is actively used for network redundancy. The vulnerability is especially dangerous in KASAN-enabled builds where memory access violations are detected and reported, making exploitation more likely to be detected but potentially leading to system crashes or privilege escalation. This issue affects the integrity of the kernel's memory management subsystem and can result in denial-of-service conditions or potential information disclosure.

The mitigation strategy involves implementing proper RCU synchronization by replacing list_del() with list_del_rcu() operations and deferring actual memory deallocation through the existing hsr_free_node_rcu() callback mechanism. This approach aligns with established kernel patterns used in HSR prune paths where nodes are already deleted using list_del_rcu() followed by call_rcu() for proper memory cleanup. The solution follows the principle of maintaining consistent lifetime management across all node deletion operations within the same subsystem, ensuring that readers can safely access data structures until after all RCU grace periods have completed. This fix addresses the core issue identified in CWE-415 and aligns with ATT&CK techniques related to kernel memory corruption and privilege escalation through improper resource management. The implementation requires careful coordination between reader and writer paths to ensure proper synchronization while maintaining system performance and avoiding deadlocks or race conditions that could impact network connectivity in redundant network environments.

Responsible

Linux

Reservation

07/19/2026

Disclosure

07/19/2026

Moderation

accepted

CPE

ready

EPSS

0.00000

KEV

no

Activities

low

Sources

Might our Artificial Intelligence support you?

Check our Alexa App!