CVE-2026-52945: Linux Kernel WireGuard DoS Vulnerability

CVE-2026-52945 Overview

CVE-2026-52945 affects the Linux kernel's WireGuard driver. The vulnerability stems from the prior commit that enabled threaded NAPI by default in the WireGuard device implementation. Under heavy networking load, the decryption path can permanently stall for a specific peer while other peers continue functioning. The fix reverts commit 933466fc50a8 to restore prior behavior.

The issue was reported in production deployments using Cilium with WireGuard for Kubernetes Pod east-west traffic encryption. Once triggered, the peer->rx_queue reaches its MAX_QUEUED_PACKETS limit of 1024 skbs and wg_packet_rx_poll is never rescheduled for that peer.

Critical Impact
Affected nodes lose the ability to decrypt WireGuard traffic from a specific peer until the kernel module is reloaded or the system is restarted, causing persistent connectivity loss for that tunnel.

Affected Products

Linux kernel stable series v5.15 (confirmed)
Linux kernel stable series v6.1 (confirmed)
WireGuard in-tree driver with threaded NAPI enabled by default

Discovery Timeline

2026-06-24 - CVE CVE-2026-52945 published to NVD
2026-06-24 - Last updated in NVD database

Technical Details for CVE-2026-52945

Vulnerability Analysis

The defect is an ordering and scheduling race in the WireGuard receive path introduced when threaded NAPI became the default. Incoming encrypted skbs are enqueued onto a per-peer Multi-Producer Single-Consumer queue (peer->rx_queue) by wg_queue_enqueue_per_device_and_peer. The skbs are then dispatched across CPUs to wg_packet_decrypt_worker. Workers complete decryption out of order relative to the peer queue's FIFO ordering.

When wg_packet_rx_poll runs, it peeks the head of peer->rx_queue. If the head skb's state is still PACKET_STATE_UNCRYPTED, the poll routine exits without dequeuing. Under load, the first packet can wait significantly longer than later packets to be scheduled for decryption. NAPI invocations triggered by other completed packets find the head skb unready and return early. Eventually the queue fills to MAX_QUEUED_PACKETS (1024), wg_prev_queue_enqueue begins failing, and the NAPI for that peer is never rearmed.

Root Cause

The root cause is the interaction between threaded NAPI scheduling and the ordering constraints of peer->rx_queue. Threaded NAPI changes the timing characteristics of poll invocation, exposing a livelock where the head-of-line skb remains in PACKET_STATE_UNCRYPTED while subsequent skbs complete decryption on other CPUs. The poll routine never makes forward progress for that peer.

Attack Vector

The issue is a reliability defect rather than a directly attacker-driven vulnerability. It manifests under organic high networking load on systems using WireGuard with default threaded NAPI. An adversary positioned to generate sustained encrypted traffic against a WireGuard peer could potentially accelerate the conditions that trigger the stall, resulting in denial of service for that tunnel.

No verified proof-of-concept code is available. The defect is described in the upstream kernel commit revert. See the Linux Kernel Commit Notice for technical details.

Detection Methods for CVE-2026-52945

Indicators of Compromise

Sustained failure of wg_prev_queue_enqueue for a specific WireGuard peer observable via bpftrace.
wg_packet_rx_poll no longer invoked for an affected peer while continuing to fire for other peers.
Per-peer rx_queue depth pinned at MAX_QUEUED_PACKETS (1024 skbs).
One-way connectivity loss: encryption side continues operating, decryption side stalls.

Detection Strategies

Deploy bpftrace probes on wg_prev_queue_enqueue and wg_packet_rx_poll to identify peers experiencing scheduling starvation.
Monitor WireGuard interface counters and Cilium pod-to-pod connectivity metrics for asymmetric traffic loss between nodes.
Correlate stalled connections to the peer->rx_queue depth using kernel tracing.

Monitoring Recommendations

Track per-peer packet receive rates on WireGuard interfaces and alert on sustained zero-receive states with non-zero send activity.
Instrument Kubernetes CNI health checks to detect east-west traffic stalls between specific node pairs.
Capture kernel version inventory and flag hosts running v5.15.x or v6.1.x stable kernels with threaded NAPI enabled.

How to Mitigate CVE-2026-52945

Immediate Actions Required

Upgrade to a kernel build that includes commit e94b369ff82f reverting the threaded NAPI default for WireGuard.
Audit Cilium and other WireGuard-dependent workloads for symptoms of stalled peer decryption.
For nodes already exhibiting the stall, reload the wireguard module or reboot to restore traffic flow.

Patch Information

The fix reverts commit 933466fc50a8e4eb167acbd0d8ec96a078462e9c (upstream db9ae3b6b43c79b1ba87eea849fd65efa05b4b2e), which had enabled threaded NAPI in the WireGuard device. Apply kernel updates from your distribution that include the revert. See the Linux Kernel Commit Notice for the upstream commit reference.

Workarounds

Disable threaded NAPI for WireGuard interfaces by writing 0 to /sys/class/net/<wg-iface>/threaded after interface creation.
Downgrade to a kernel where WireGuard does not default to threaded NAPI (for example, v5.10 stable, which was reported unaffected).
Reduce sustained per-peer traffic concurrency if upgrade or configuration change is not immediately feasible.

bash

# Disable threaded NAPI on a WireGuard interface as a runtime workaround
echo 0 | sudo tee /sys/class/net/wg0/threaded

# Verify the setting
cat /sys/class/net/wg0/threaded