CVE-2026-97419: hsr: broadcast netlink notifications in the device's net namespace
In the Linux kernel, the following vulnerability has been resolved:
hsr: broadcast netlink notifications in the device's net namespace
The HSR generic netlink family sets .netnsok = true. HSR devices can live in network namespaces other than initnet.
Two async notifiers broadcast events with genlmsgmulticast(). They are hsrnlringerror() and hsrnlnodedown(). That helper delivers only on the default genl socket in initnet. So the events always land in initnet. The network namespace of the device does not matter.
This has two effects. A listener in the device's own namespace never sees its own ring error and node down events. A privileged listener in initnet receives events from HSR devices in other namespaces. The payload carries the peer node MAC (HSRANODEADDR) and the slave port ifindex (HSRAIFINDEX).
Switch both callers to genlmsgmulticastnetns(). Other families with .netnsok = true already do this. Examples are gtp, ovpn, team, batman-adv, netdev-genl, ethtool and handshake.
hsrnlringerror() already has the slave port. It uses devnet(port->dev). hsrnlnodedown() takes the namespace from the master port via hsrportgethsr().
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
In the Linux kernel HSR generic netlink implementation, switch both asynchronous notification callers, hsr_nl_ringerror() and hsr_nl_nodedown(), from genlmsg_multicast() to genlmsg_multicast_netns() so events are broadcast in the device's network namespace.
Event History
Frequently Asked Questions
Which systems are exposed to the notification leak or missed notifications?
Systems using HSR devices in network namespaces other than init_net are affected. Their ring-error and node-down events are sent to init_net rather than to the namespace containing the HSR device.
What access would an attacker or observer need?
A privileged listener in init_net can receive HSR events generated by devices in other network namespaces. The exposed event payload includes the peer node MAC address and the slave-port interface index.
What operational impact occurs for workloads using HSR in a non-default network namespace?
Listeners in the HSR device's own network namespace do not receive that device's ring-error or node-down notifications. This can prevent namespace-local monitoring from observing those events.
What change resolves the namespace-routing problem?
The resolved implementation sends the affected notifications with genlmsg_multicast_netns() and selects the namespace from the relevant HSR port, rather than using genlmsg_multicast(), which delivers through init_net.