CVE-2024-26707

What it actually does

Unnecessary WARN_ONCE triggered on skb allocation failure in hsr_init_skb called from send_hsr_supervision_frame and send_prp_supervision_frame, producing kernel backtraces under timer softirq context.

Why it matters to the business

Kernel log spam and potential alert fatigue for operators running HSR/PRP networks; no data loss, privilege escalation or service disruption results from the condition itself.

How an attack unfolds

An attacker or fuzzer induces repeated allocation failures for supervision frames; the kernel hits the WARN_ONCE, emitting stack traces via the timer path, but the code path already handles the failure gracefully.

How to fix it

Apply the upstream fix commit 0d8011a878fdf96123bc0d6a12e2fe7ced5fddfb or later; rebuild and deploy the patched kernel; no configuration changes required.

How to confirm the fix worked

Confirm absence of the WARN_ONCE line in net/hsr/hsr_device.c after patching; verify that netdev_warn_once is used instead; run existing HSR test suites under memory pressure.

Typical attack path

1. Trigger resource pressure or use syzkaller to force hsr_init_skb to fail
2. HSR supervision timer fires and calls send_hsr_supervision_frame
3. WARN_ONCE at net/hsr/hsr_device.c:294 fires, dumping stack to dmesg

How to detect it

Search kernel logs and dmesg for the strings "HSR: Could not send supervision frame" and the associated WARNING backtrace originating from send_hsr_supervision_frame; correlate with timer softirq activity.

• HSR: Could not send supervision frame
• WARNING: CPU.*send_hsr_supervision_frame
• net/hsr/hsr_device.c:294

What your security team should do

• Patch kernels to the fixed commit within normal maintenance windows
• Suppress or rate-limit the legacy warning string in SIEM until patches are complete
• Review HSR deployments for any custom monitoring that would be affected by log volume