CVE-2026-64000

What it actually does

This Linux kernel flaw is an out-of-bounds memory access in the HSR/PRP networking code while handling HSR supervision frames. A malformed or truncated supervision frame can cause the kernel to read beyond the linearized packet buffer because the full TLV header was not guaranteed to be present before parsing. Depending on kernel build, memory layout, and runtime conditions, exploitation may lead to kernel crash, information disclosure, or potentially kernel memory corruption with elevated impact. The CVSS vector indicates unauthenticated network reachability and high confidentiality, integrity, and availability impact, but practical exposure is most relevant on systems with HSR/PRP networking enabled or reachable on networks where crafted Layer 2 HSR traffic can be delivered.

Why it matters to the business

Affected Linux systems that use HSR/PRP networking could be crashed or destabilized by malformed network traffic, potentially interrupting industrial, high-availability, telecom, embedded, or infrastructure workloads that rely on redundant Ethernet. Although EPSS is currently low and there is no known KEV listing or public exploit maturity, the high severity score means organizations should treat exposed systems as important patch candidates, especially where Linux hosts process untrusted Layer 2 traffic or run in operational technology and high-availability network segments.

How an attack unfolds

An attacker first identifies a Linux system or appliance that has HSR/PRP networking support active and is reachable on the same relevant network segment or traffic path. The attacker then crafts an HSR supervision frame with a truncated TLV header. When the vulnerable kernel receives and parses the malformed frame, the HSR supervision-frame handling path attempts to access TLV data that has not been fully linearized into the packet buffer. This can trigger an out-of-bounds access in kernel context. The most likely observable result is a kernel warning, oops, panic, interface disruption, or host crash; more advanced exploitation would require controlling memory layout and kernel behavior to turn the invalid access into broader memory corruption or information exposure.

How to fix it

Upgrade to a Linux kernel version that includes the HSR supervision-frame parsing fix adding the full TLV header length to the pskb_may_pull() validation. Because no specific fixed package versions were provided, use the latest vendor-supported kernel for the affected distribution, appliance, or embedded platform and confirm that the upstream fix for net/hsr supervision TLV linearization is included. Where immediate patching is not possible, reduce exposure by disabling HSR/PRP functionality if unused, unloading or preventing loading of the hsr module where operationally safe, restricting untrusted Layer 2 access to HSR interfaces, segmenting management and production networks, and applying switch-level controls to limit unauthorized hosts from injecting HSR traffic.

How to confirm the fix worked

Confirm remediation by verifying the running kernel package is at or above the vendor-fixed version and that the applied kernel source or vendor changelog includes the HSR TLV linearization fix in the net/hsr code path. Check whether HSR is enabled by reviewing loaded modules and interfaces, for example looking for the hsr module and HSR network devices. Validate that systems have rebooted into the patched kernel, not merely installed it. For exposure validation, confirm whether interfaces of type hsr exist, whether the hsr kernel module is loaded, and whether untrusted hosts can send Layer 2 traffic to those interfaces. In test environments only, malformed-frame regression testing should confirm that truncated HSR supervision frames are dropped safely without kernel oops, panic, or warning output.

Typical attack path

1. Identify Linux systems, appliances, or embedded devices using HSR/PRP networking or loading the hsr kernel module.
2. Gain the ability to send crafted HSR supervision frames to the target network segment or interface.
3. Create a malformed or truncated HSR supervision frame with an incomplete TLV header.
4. Transmit the crafted frame to the vulnerable system.
5. Trigger the vulnerable kernel parsing path during HSR supervision-frame handling.
6. Cause kernel instability, crash, denial of service, or potentially broader memory exposure/corruption depending on exploit reliability and kernel configuration.

How to detect it

There are no public, reliable exploit-specific indicators for this vulnerability. Detection should focus on evidence of attempted malformed HSR traffic and kernel-side instability. Review kernel logs, system journals, crash dumps, and network telemetry for oops, panic, general protection faults, slab/KASAN reports, or interface resets involving HSR code paths. On Linux systems, inspect dmesg, journald, /var/log/kern.log, /var/log/messages, /var/crash, kdump artifacts, and distribution-specific ABRT/apport crash records. Network detection is difficult because exploitation occurs via crafted HSR supervision frames at Layer 2; where packet capture is available, look for unusual HSR supervision frames, malformed/truncated frames, repeated HSR traffic from unauthorized MAC addresses, or bursts of HSR frames immediately preceding a kernel crash or reboot. Correlate suspicious HSR traffic with host reboot timestamps, kernel panic records, watchdog resets, or HA failover events.

• hsr
• hsr_sup_tlv
• hsr_handle_sup_frame
• hsr_rcv
• net/hsr
• BUG: kernel NULL pointer dereference
• BUG: unable to handle kernel paging request
• general protection fault
• kernel BUG at net/hsr
• KASAN: slab-out-of-bounds
• KASAN: global-out-of-bounds
• Oops:
• Kernel panic - not syncing
• Call Trace:
• /var/log/kern.log
• /var/log/messages
• /var/crash
• /var/lib/systemd/coredump
• /var/spool/abrt
• /var/crash/linux-image

What your security team should do

• Prioritize patching Linux systems that use HSR/PRP networking, redundant Ethernet, industrial networking, telecom infrastructure, embedded gateways, or high-availability network designs.
• Inventory systems for loaded hsr modules and HSR interfaces to identify where the vulnerable code path may be reachable.
• If HSR/PRP is not required, disable the feature and prevent the hsr module from loading until patching is complete.
• Restrict Layer 2 access to HSR-capable network segments and prevent unauthorized devices from injecting raw Ethernet traffic.
• Monitor kernel logs for crashes, oops messages, or warnings involving HSR supervision-frame handling, especially on systems with recent unexplained reboots or interface resets.
• Ensure patched kernels are actually running after maintenance by validating reboot status and kernel version across the fleet.
• Track vendor advisories for exact fixed versions because distribution backports may fix the issue without changing to the latest upstream kernel version.