CVE-2026-100071: net: hsr: free learned nodes on device setup failure
In the Linux kernel, the following vulnerability has been resolved:
net: hsr: free learned nodes on device setup failure
hsrdevfinalize() 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 nodedb, and the error unwind never releases them.
Free both owned dynamic databases in the unwind, mirroring hsrdellink(). proxynodedb 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: hsrdelport() unregisters each RX handler with synchronizenet() before hsrdelnodes() runs, which removes remaining entries with listdelrcu() and defers their release with callrcu() for readers already under RCU.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
Update hsr_dev_finalize() error unwinding to free both owned dynamic databases, including learned nodes in node_db and proxy_node_db, mirroring hsr_del_nodes().
Event History
Frequently Asked Questions
When can the leaked node entries be created?
They can be learned when device setup fails after the first lower-device RX handler has been registered and before setup completes. Received frames are still processed by RX handlers in softirq during that window, regardless of the master device state.
What condition is needed to trigger the leak?
An HSR device setup must fail after slave A is added, while the RX handler is already registered, and traffic must arrive that causes dynamic nodes to be learned into node_db. The previous error-unwind path did not release those learned entries.
Is there a concurrency concern when cleaning up learned nodes?
The cleanup order unregisters RX handlers through hsr_del_port() and waits with synchronize_net() before deleting nodes. Remaining entries are removed with list_del_rcu() and released through call_rcu(), protecting readers already operating under RCU.