CVE-2026-53353: Linux Kernel HSR Warning Denial—CVSS 5.5 Medium

Technical summary

The vulnerability exists in `net/hsr/hsr_framereg.c` within the HSR frame registration logic. When an HSR interface is deleted via `hsr_dellink()`, the `hsr_del_self_node()` function clears the `hsr->self_node` pointer. However, `dev->rtnl_link_ops->dellink()` is invoked before `unregister_netdevice_many()`, creating a race window where the device remains discoverable but lacks its self_node reference. If packet forwarding logic in `hsr_forward_skb()` calls `hsr_addr_is_self()` during this window, a kernel WARN_ONCE() macro fires with the message 'HSR: No self node.' The warning itself does not prevent packet processing, but it incorrectly signals a logic error. The fix removes the WARN_ONCE() call because the condition it guards—missing self_node during device teardown—is a normal, expected state, not an error condition. No functional change to HSR forwarding or address validation occurs.

Business impact

This vulnerability causes kernel warning spam during routine HSR interface teardown, degrading system observability and potentially triggering automated alert systems. While not a functional failure, persistent warnings in production logs can obscure genuine errors and create false-positive security alerts. Systems relying on HSR for redundant networking (industrial control, telecommunications, automotive systems) may experience disrupted monitoring and false incident escalations. The impact is primarily operational and diagnostic rather than a direct security compromise. Administrators managing HSR deployments must suppress or tolerate spurious warnings until patching, consuming log analysis resources.

Affected systems

Only Linux systems with HSR (High-availability Seamless Redundancy) interfaces configured are affected. HSR is a specialized redundancy protocol used in industrial and critical infrastructure networks, not enabled by default in standard Linux distributions or typical enterprise deployments. Affected configurations include embedded systems, automotive networking stacks, process control networks, and telecommunications equipment implementing HSR for fault tolerance. Versions prior to the fix commit are vulnerable; specific version numbers depend on the kernel branch and distribution's backport status. Users without explicit HSR interface configuration are unaffected.

Exploitability

This vulnerability is not exploitable in the traditional sense. It does not enable privilege escalation, information disclosure, or denial of service through network packets or user-triggered events. The condition is triggered only during the legitimate, expected teardown of an HSR interface—a privileged administrative operation. An unprivileged attacker cannot independently trigger the warning. However, local privileged users (or processes with CAP_NET_ADMIN capability) can repeatedly create and delete HSR interfaces to generate warnings. The issue is a kernel logging artifact exposed by syzbot's fuzzing, not a security vulnerability enabling unauthorized actions or system compromise. It is best classified as a code quality issue with minimal real-world security risk.

Remediation

Apply the upstream kernel patch that removes the WARN_ONCE() call from `hsr_addr_is_self()`. The fix is non-invasive—a single-line deletion—and carries no risk of functional regression since the warning itself served no operational purpose beyond signaling an erroneous assumption. Backports for stable kernel series (5.15, 6.1, 6.6, 6.9, and later) are expected. Distributions shipping HSR modules (embedded Linux, automotive platforms) should incorporate this fix in their next kernel updates. No workaround exists beyond disabling HSR entirely or tolerating warnings in kernel logs.

Patch guidance

Identify your Linux kernel version and distribution. If your system runs an HSR interface, check your vendor's security advisory for patch availability. Distributions including HSR support should provide a kernel update containing this fix within their normal security release cadence. For custom or embedded builds, apply the upstream commit directly to the HSR frame registration module. Testing should verify that HSR interfaces can be created and destroyed without warnings appearing in `dmesg` or syslog. No configuration changes or runtime parameters require adjustment; the patch is transparent to HSR operation.

Detection guidance

Search kernel logs for the pattern 'HSR: No self node' warnings emitted from `hsr_framereg.c:39`. These warnings are most visible when HSR interfaces are frequently created or destroyed (e.g., during interface failover, testing, or automated network reconfiguration). On production systems with long-running HSR interfaces that are rarely torn down, warnings may not appear. Monitor for spikes in kernel warnings correlated with HSR interface lifecycle events. Automated log analysis should suppress or ignore this specific warning once patched, to prevent false-positive incident tickets.

Why prioritize this

This is a low-urgency patch for most deployments due to its limited exploitability and scope. Prioritize it for systems actively using HSR (industrial control networks, telecom equipment, redundant networking stacks) where HSR interfaces are frequently provisioned or deprovisioned. Standard enterprise and cloud infrastructure without HSR configuration can defer patching. The CVSS 5.5 MEDIUM score reflects the local, privileged-user requirement and the lack of real security impact; availability impact is limited to kernel logging artifacts rather than operational disruption. Schedule patching in routine maintenance windows rather than emergency cycles.

Risk score, explained

CVSS 3.1 score of 5.5 MEDIUM reflects: (1) Local-only attack vector (AV:L)—only privileged local users can trigger the condition; (2) Low attack complexity (AC:L)—trivial to reproduce via interface teardown; (3) Privilege required (PR:L)—CAP_NET_ADMIN or root needed; (4) No user interaction (UI:N); (5) No confidentiality or integrity impact (C:N, I:N); (6) High availability impact (A:H)—kernel warnings degrade observability and could trigger automated alerting. The score reflects operational/diagnostic impact rather than direct system compromise. In practice, real-world risk is lower because HSR is niche, and warnings do not prevent HSR function.

Frequently asked questions