CVE-2026-53353: Linux Kernel Privilege Escalation Flaw

CVE-2026-53353 Overview

CVE-2026-53353 is a Linux kernel vulnerability in the High-availability Seamless Redundancy (HSR) subsystem. The issue was reported by the syzbot fuzzer and stems from an incorrect assumption in hsr_addr_is_self() about the lifetime of hsr->self_node. A race window exists between hsr_dellink() clearing the self node and the completion of unregister_netdevice_many(), allowing user-triggered code paths to reach the function while hsr->self_node is already cleared. The kernel fix removes the WARN_ONCE() in hsr_addr_is_self(), since the warning's precondition is invalid during teardown.

Critical Impact
Local users can trigger a kernel warning through concurrent HSR device operations, producing log noise and potential panics on systems configured with panic_on_warn.

Affected Products

Linux kernel (mainline) — HSR networking subsystem in net/hsr/hsr_framereg.c
Stable kernel branches receiving backports referenced by the commits 0232b6fcb761, 271355c2ef61, 66a46e22396f, afd0f17ca462, and d71bb171661e
Distributions shipping affected kernel versions with the HSR module enabled

Discovery Timeline

2026-07-01 - CVE-2026-53353 published to NVD
2026-07-01 - Last updated in NVD database

Technical Details for CVE-2026-53353

Vulnerability Analysis

The High-availability Seamless Redundancy (HSR) protocol implementation in the Linux kernel maintains a self_node structure on each HSR device to identify frames originating locally. The function hsr_addr_is_self() at net/hsr/hsr_framereg.c:39 previously contained a WARN_ONCE() that fired if hsr->self_node was NULL, under the assumption that the field remained valid for the lifetime of the device.

That assumption is incorrect. The rtnl link operation dellink invokes hsr_dellink(), which calls hsr_del_self_node() and clears hsr->self_node before unregister_netdevice_many() runs. During this interval the netdevice is still discoverable, and concurrent transmit paths can dispatch frames into hsr_forward_skb(), reaching check_local_dest() and then hsr_addr_is_self() with a NULL self_node.

The syzbot reproducer triggers the warning through a raw IPv4 socket sending via sendmsg(), which flows through ip_finish_output2(), __dev_queue_xmit(), and finally hsr_dev_xmit(). On kernels built with panic_on_warn, the resulting warning escalates into a kernel panic and denial of service.

Root Cause

The root cause is an invalid invariant assumed by the WARN_ONCE() check. The rtnetlink deletion path clears device state before the netdevice becomes invisible to transmitters, producing a legitimate window in which hsr->self_node is NULL for an in-flight packet. This is a race condition [CWE-362] between HSR device teardown and frame forwarding.

Attack Vector

Exploitation requires local access and the ability to create and delete HSR network devices, typically limited to processes with CAP_NET_ADMIN. An attacker races an HSR device removal against traffic transmission through the same device. The fix simply removes the WARN_ONCE() in hsr_addr_is_self(), allowing the existing NULL check to return gracefully without alarming the kernel log.

No verified public exploit code is available. Refer to the kernel commit removing the WARN_ONCE for the authoritative patch.

Detection Methods for CVE-2026-53353

Indicators of Compromise

Kernel log entries containing the string HSR: No self node followed by a warning at net/hsr/hsr_framereg.c:39
Stack traces referencing hsr_addr_is_self, check_local_dest, hsr_forward_skb, and hsr_dev_xmit
Unexpected kernel panics on hosts with panic_on_warn=1 that coincide with HSR interface deletions

Detection Strategies

Monitor dmesg and journalctl -k for the specific warning signature at hsr_framereg.c:39
Correlate RTM_DELLINK netlink events targeting HSR interfaces with kernel warning timestamps
Track processes invoking ioctl or rtnetlink operations on HSR devices in short succession with transmit activity

Monitoring Recommendations

Forward kernel logs to a centralized log platform and alert on the hsr_addr_is_self warning signature
Audit which local accounts and containers hold CAP_NET_ADMIN and can manipulate HSR devices
On systems that do not require HSR, confirm the hsr module is not loaded via lsmod | grep hsr

How to Mitigate CVE-2026-53353

Immediate Actions Required

Apply the upstream kernel patch removing the WARN_ONCE() in hsr_addr_is_self() or upgrade to a stable kernel release containing the referenced commits
Disable panic_on_warn on hosts that do not require it, to prevent kernel warnings from escalating into denial of service
Restrict CAP_NET_ADMIN in untrusted containers and multi-tenant workloads to limit local trigger paths

Patch Information

The fix is delivered by the mainline commit 271355c2ef6171dbc815e7ae653eed63444bbd58 and backported through commits 0232b6fcb7615fb7fecfe0727a23065a53e228b8, 66a46e22396fd5d09606f37f73643eb20e99aa42, afd0f17ca46258cec3a5cc48b8df9327fe772490, and d71bb171661ec0225bf4babdd4d296d744982fb3. See the Linux kernel stable tree for the authoritative patch.

Workarounds

Blacklist the hsr kernel module on systems that do not use HSR redundancy
Set kernel.panic_on_warn=0 at runtime via sysctl to prevent panics from this warning
Avoid deleting HSR interfaces while active traffic is in flight on the same device

bash

# Prevent the warning from escalating to a panic and disable HSR where unused
sudo sysctl -w kernel.panic_on_warn=0
echo "blacklist hsr" | sudo tee /etc/modprobe.d/blacklist-hsr.conf
sudo modprobe -r hsr 2>/dev/null || true