EUVD-2026-87068
GHSA-rfjf-r326-rpvj
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessObtain CAP_NET_ADMIN on host
-
DeliveryConfigure HSR device so finalize fails mid-setup
-
ExploitReceive frames in the RX window to learn nodes
-
ExecutionRepeat to leak node_db entries
-
ImpactExhaust kernel memory / degrade availability
Vulnerability Assessment
| Exploitation Conditions | Requires the Linux HSR subsystem (CONFIG_HSR) to be present and a local actor with network-administration privilege (CAP_NET_ADMIN, consistent with PR:L) able to create and configure HSR master/slave/interlink devices. The leak is triggered specifically when hsr_dev_finalize() fails AFTER the first lower device's RX handler is already registered (e.g. a later failable slave or interlink add fails) AND frames arrive in that softirq RX window to learn dynamic nodes into node_db. Limiting factors: it is not remotely reachable (AV:L), needs privileged interface configuration, depends on a setup failure plus a receive-timing race, and produces only gradual resource exhaustion rather than code execution or data exposure - so realistic impact is bounded to local denial of service on hosts that actually deploy HSR (largely industrial/substation redundant-network scenarios). |
| Impact | This is a genuinely low-priority issue despite a 'Medium' CVSS of 5.5. All signals align toward low real-world risk: the CVSS vector (AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H) describes a local, authenticated availability-only impact with no confidentiality or integrity consequence; EPSS is 0.16% (5th percentile), indicating negligible predicted exploitation; the CVE is NOT in CISA KEV; and no public exploit code is referenced. SSVC framing would be exploitation=none, automatable=no (requires local privileged configuration plus a device-setup failure), technical impact=partial (resource leak, not takeover). The one notable data conflict: the input Tags label this 'Information Disclosure', but the CVSS vector explicitly sets C:N and A:H - this is a kernel memory LEAK (node_db dynamic entries not freed on hsr_dev_finalize() unwind), i.e. a resource-exhaustion/availability defect, NOT disclosure. The 'Information Disclosure' tag appears mislabeled and should not drive prioritization. Net: a real but low-severity local memory-leak bug, appropriately patched upstream, not an urgent operational priority. |
| Exploit ScenarioDerived | A local user with network-administration capability repeatedly configures an HSR (High-availability Seamless Redundancy) interface in a way that causes hsr_dev_finalize() to fail after the first slave's RX handler is already registered; frames received in that window learn dynamic nodes that the error path never frees. Repeating this leaks kernel memory on each failed setup, gradually exhausting resources and degrading or crashing the host. No public exploit code is identified at time of analysis, and the memory leak depends on a specific failure-plus-receive timing window, making reliable triggering non-trivial. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 21, 2026
Memory exhaustion in the Linux kernel's HSR (High-availability Seamless Redundancy) networking code allows a local user holding CAP_NET_ADMIN to leak kernel heap allocations by repeatedly driving HSR device setup into its failure path. Because the first slave's RX handler is registered in softirq before later failable steps (second slave, interlink), frames arriving in that window learn dynamic entries into node_db, and the error unwind never frees them - so repeated failed configurations steadily grow kernel memory use and can degrade or crash the host (availability-only impact, no code execution or data exposure). Exploitation requires the CONFIG_HSR subsystem plus privileged interface configuration and a setup-failure/timing race, so realistic exposure is confined to hosts that actually deploy HSR, largely industrial and substation redundant-network scenarios; EPSS is 0.16% (5th percentile), there is no CISA KEV listing, and no public exploit was identified at time of analysis.
RemediationAI
Vendor-released patch: upgrade to Linux 6.1.188, 6.6.157, 6.12.110, 6.18.52, or 7.2.6 (mainline 7.3-rc1) - the specific stable commit for each branch is linked from https://git.kernel.org/stable/c/e691eee886871b933d772ffc76d66c80b4c0a25e, and the distro kernel should be updated once it rebases onto these tags. If an immediate upgrade is not possible, the most effective compensating control is to remove the attack surface: if HSR is not in use, ensure CONFIG_HSR is not built in, or blacklist/do not load the hsr module and drop any modprobe alias, at the cost of breaking HSR redundant-ring networking entirely. Where HSR is required, tightly restrict CAP_NET_ADMIN to a small set of trusted administrators (e.g. via capabilities-aware privilege management, not broad sudo), since the leak only triggers when a privileged actor creates and then fails HSR device setup; this reduces but does not eliminate exposure from an operator making a mistake. Operators can also monitor kernel slab/heap growth attributable to the hsr module and alert on sustained growth after failed HSR interface creations, which detects abuse but does not prevent the leak.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
HSR is the IEC 62439-3 seamless redundancy protocol implemented in the kernel under CONFIG_HSR, where an HSR master is composed of two slave ports plus an optional interlink. hsr_dev_finalize() brings these up in sequence and registers each lower device's RX handler as it goes; those handlers execute in softirq context regardless of whether the master has finished coming up, so a frame received between the first successful slave add and a subsequent failure can install dynamic MAC entries into the per-master node_db. The upstream fix frees both owned dynamic databases on the error unwind, mirroring hsr_dellink(); proxy_node_db is provably empty on current error exits (only interlink RX feeds it, and the interlink add is the last failable step) and is freed for symmetry. The teardown order is race-free: hsr_del_port() unregisters each RX handler under synchronize_net() before hsr_del_nodes() removes remaining entries with list_del_rcu() and defers freeing via call_rcu() for readers already inside RCU sections. The feed provides no CWE mapping; the root-cause class is a memory leak / uncontrolled resource consumption in an error path. The authoritative assessment rates this AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H - local, privileged, race-dependent, availability-only.
Know when the next one hits your stack
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Local HSR config requires CAP_NET_ADMIN (PR:L); the leak depends on a setup-failure plus RX race window (AC:H); impact is availability-only (A:H), no C/I.
Primary rating from NVD.
CVSS VectorNVD
Lifecycle Timeline
4DescriptionNVD
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.
Threat Intelligence Overview
NVD
CVE.org
EPSS
VulDB
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
Exploit-DB