CVE-2026-53353

What it actually does

This is a Linux kernel denial-of-service class issue in the HSR/PRP networking subsystem. During deletion of an HSR network interface, the kernel can briefly expose an HSR device after its self-node state has already been cleared. If packet forwarding logic reaches hsr_addr_is_self() during that race window, an invalid WARN_ONCE() assumption is triggered, producing a kernel warning. Depending on kernel configuration and operational policy, repeated warnings or panic-on-warn settings can degrade availability or crash the host.

Why it matters to the business

Systems using Linux HSR/PRP networking, especially high-availability or industrial networking deployments, may experience instability or outage if the vulnerable code path is triggered. The risk is reduced because exploitation appears to require local ability to manipulate or interact with HSR interfaces, there is no known public exploit maturity, EPSS is very low, and it is not listed in CISA KEV; however, environments configured to panic on kernel warnings should treat this as a higher availability risk.

How an attack unfolds

An attacker with sufficient local network administration capability, or access to a workload/container granted relevant networking capabilities, creates or uses an HSR interface and races interface deletion against traffic transmission. The vulnerable timing occurs after HSR self-node state is cleared but before the network device is fully unregistered. If traffic processing reaches the HSR forwarding path during that window, hsr_addr_is_self() encounters a missing self-node and triggers the kernel warning. On systems where kernel warnings are fatal, this can cause an immediate crash; otherwise it may create noisy kernel logs and potential service degradation if repeatedly triggered.

How to fix it

Apply the Linux kernel update from the relevant distribution or kernel vendor that includes the HSR fix removing the invalid WARN_ONCE() in hsr_addr_is_self(). No exact fixed package versions were provided, so track vendor advisories for the running kernel branch and update to the first fixed kernel or later. If HSR/PRP networking is not required, disable or avoid loading the hsr kernel module and remove unused HSR interfaces. Reduce exposure by limiting CAP_NET_ADMIN and CAP_NET_RAW, avoiding privileged containers, restricting creation of network namespaces and virtual network devices, and ensuring untrusted users cannot administer host networking. Where feasible, review panic-on-warn settings because they can turn a warning-only bug into a full system outage.

How to confirm the fix worked

Confirm the running kernel includes the vendor patch for the HSR hsr_addr_is_self() warning removal, or verify the source/package changelog contains the fix for this issue. Check that all nodes have rebooted into the updated kernel, not merely installed it. Validate whether the hsr module is loaded with lsmod or equivalent, and confirm whether HSR interfaces are present using ip link. For mitigation validation, confirm untrusted users and containers do not have CAP_NET_ADMIN, CAP_NET_RAW, or privileged networking access. After patching, monitor dmesg, journalctl -k, and kernel logs for absence of the HSR warning during HSR interface creation/deletion and traffic tests.

Typical attack path

1. Gain local access to a Linux system or container with sufficient networking privileges, such as CAP_NET_ADMIN and potentially CAP_NET_RAW.
2. Create, configure, or identify an HSR interface on the host.
3. Initiate deletion of the HSR interface while concurrently sending traffic through or toward the interface.
4. Trigger the race window where the HSR device is still reachable but hsr->self_node has already been cleared.
5. Cause the kernel to emit the HSR warning in hsr_addr_is_self().
6. If panic-on-warn or equivalent hardening/debug behavior is enabled, cause a host crash; otherwise, cause kernel log noise and possible operational instability.

How to detect it

Look for evidence in kernel logs that the HSR warning path was triggered. Relevant sources include dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, /var/log/syslog, crash dumps, kdump/vmcore artifacts, and EDR telemetry for privileged network interface manipulation. Search for the exact warning text, function names, and stack frames associated with HSR forwarding. Correlate any matches with recent creation or deletion of HSR links, privileged container activity, network namespace changes, raw socket send activity, or commands such as ip link add/delete involving type hsr. On systems configured with panic_on_warn, also review unexpected reboots, kernel panic records, watchdog events, and crash dumps around the same timestamps. There are no network-only indicators that reliably prove exploitation because the trigger is a local kernel race involving HSR device teardown and packet transmission.

• HSR: No self node
• WARNING: net/hsr/hsr_framereg.c:39
• hsr_addr_is_self
• check_local_dest net/hsr/hsr_forward.c
• fill_frame_info net/hsr/hsr_forward.c
• hsr_forward_skb
• hsr_dev_xmit
• net/hsr/hsr_device.c
• net/hsr/hsr_framereg.c
• net/hsr/hsr_forward.c
• ip link add type hsr
• ip link delete
• type hsr

What your security team should do

• Prioritize patching systems that use HSR/PRP interfaces, run panic-on-warn, host privileged containers, or allow delegated network administration.
• Inventory Linux hosts for loaded hsr modules and active HSR interfaces using configuration management or endpoint telemetry.
• Apply vendor kernel updates and reboot into the fixed kernel; verify the active kernel version after reboot.
• If HSR is unused, disable the hsr module and remove unused HSR network configuration.
• Restrict CAP_NET_ADMIN and CAP_NET_RAW from containers and non-administrative users; avoid privileged containers unless strictly required.
• Add detection for kernel logs containing the HSR warning and related stack traces to identify attempted triggering or instability.
• Because the issue is not in KEV, has low EPSS, and has no known exploit maturity, handle as availability-focused hardening unless local exposure or critical HSR usage increases risk.