CVE-2026-100071 in Linux
Summary
by MITRE • 09/25/2026
In the Linux kernel, the following vulnerability has been resolved:
net: hsr: free learned nodes on device setup failure
hsr_dev_finalize() can fail after a lower-device RX handler has already been registered (slave A is added before the failable slave B and interlink adds). RX handlers run in softirq regardless of the master's state, so frames received in that window can learn dynamic nodes into node_db, and the error unwind never releases them.
Free both owned dynamic databases in the unwind, mirroring hsr_dellink(). proxy_node_db is provably empty on every current error exit (only interlink RX feeds it, and the interlink add is the last failable step) and is freed for symmetry. The order is safe: hsr_del_port() unregisters each RX handler with synchronize_net() before hsr_del_nodes() runs, which removes remaining entries with list_del_rcu() and defers their release with call_rcu() for readers already under RCU.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/25/2026
The Linux kernel High-availability Seamless Redundancy (HSR) protocol implementation contains a resource management flaw within the device initialization sequence that can lead to memory leaks when setup operations fail after partial registration of network handlers. This vulnerability specifically affects the hsr_dev_finalize function, which is responsible for completing the configuration of an HSR master device by integrating its slave ports and interlinks. The core issue arises from a race condition in the error handling path where lower-level devices are added sequentially. If the first slave port is successfully registered before a subsequent failable component such as the second slave or the interlink fails to initialize, the kernel has already installed receive handlers for the successful portion of the device configuration. These RX handlers operate within softirq context and remain active even if the overall master device setup subsequently aborts due to an error in later steps.
During this window between partial registration and final failure unwind, incoming network frames are processed by the registered receivers. The HSR protocol logic interprets these packets as valid traffic from peer nodes and dynamically populates its internal node database with MAC addresses learned from these frames. Because the initialization process fails before reaching a state where cleanup is fully coordinated, the standard error exit path does not account for these newly allocated dynamic entries in the node_db structure. Consequently, when hsr_dev_finalize returns an error code to trigger device teardown, it proceeds to free static resources but neglects to release the dynamically learned nodes that were inserted into memory during the brief period of partial operation. This results in a persistent memory leak within the kernel space associated with each failed HSR device setup attempt.
The operational impact of this vulnerability is primarily characterized by gradual memory consumption degradation on systems frequently attempting to configure or reconfigure HSR interfaces under error conditions. While individual leaks may be small, repeated failures can accumulate over time, potentially leading to resource exhaustion in constrained environments such as embedded industrial control systems or network appliances that rely heavily on high-availability redundancy protocols for critical infrastructure protection. Furthermore, the presence of stale entries in the node database could theoretically interfere with subsequent successful configurations if not properly cleared, although the primary risk remains the uncontrolled allocation of kernel memory structures without corresponding deallocation mechanisms.
To address this issue, the fix implements a comprehensive cleanup routine within the error unwind path that explicitly frees both owned dynamic databases. This approach mirrors the logic used in hsr_dellink to ensure consistency between normal teardown and failure-induced teardown sequences. The implementation carefully manages proxy_node_db which is verified to be empty on all current error exit paths since it is only populated by interlink RX operations, and the interlink addition occurs as the final failable step before completion. By freeing this database for symmetry, the code maintains logical consistency even if no actual data resides there during failure scenarios.
The safety of this memory release operation relies on strict ordering guarantees provided by RCU (Read-Copy-Update) synchronization primitives. The cleanup sequence invokes hsr_del_port which first unregisters each RX handler using synchronize_net to ensure that all currently executing softirq contexts have completed before proceeding. Only after these handlers are safely detached does the code execute hsr_del_nodes, which removes remaining entries from the node list using list_del_rcu and defers their actual memory release via call_rcu. This deferred freeing mechanism ensures that any readers still traversing the RCU-protected lists during the transition period will not encounter use-after-free conditions, thereby maintaining kernel stability while correcting the resource leak defect in accordance with standard Linux kernel concurrency best practices.