CVE-2026-52945: Linux Kernel WireGuard Decryption Stall Vulnerability

Technical summary

The vulnerability arises from an ordering problem in WireGuard's packet decryption pipeline introduced by commit db9ae3b ("wireguard: device: enable threaded NAPI"). The issue occurs when packets arrive for decryption and are enqueued to a peer's rx_queue via wg_queue_enqueue_per_device_and_peer, which enforces a MAX_QUEUED_PACKETS limit of 1024 skbs per peer. Under heavy load, the per-CPU decryption worker threads can complete decryption out-of-order relative to arrival sequence. When this happens, the NAPI polling routine (wg_packet_rx_poll) encounters an out-of-order skb whose decryption is not yet complete, causing it to exit early. Subsequently, no further napi_schedule calls occur for that peer, leaving remaining queued packets permanently stuck. The queue fills to capacity, wg_prev_queue_enqueue fails on new arrivals, and the decryption path ceases for that peer entirely while others operate normally. Notably, the encryption path is unaffected.

Business impact

Organizations operating WireGuard-encrypted Kubernetes networks, particularly those using Cilium for pod-to-pod encryption, face intermittent but critical connectivity loss. Affected nodes experience complete unidirectional communication failure for specific peer connections under production load, manifesting as network timeouts and service unavailability. Because the issue occurs rarely but randomly and never self-recovers without system restart, it presents significant operational risk for high-availability environments. The stall is transparent to standard monitoring (CPU, memory, and process-level metrics appear normal), potentially causing confusion during incident response. Recovery requires manual node intervention, impacting cluster resilience.

Affected systems

The Linux kernel in versions v5.15 stable and v6.1 stable are confirmed affected when WireGuard is deployed. The issue does not occur in v5.10 stable (pre-threaded NAPI implementation) or v6.6 stable. Any system running WireGuard on affected kernel versions, particularly in containerized or Kubernetes environments using Cilium with WireGuard underlay encryption for east-west traffic, is at risk. The vulnerability requires specific conditions: heavy networking load, multiple peer connections, and the threaded NAPI feature enabled (the default in affected versions).

Exploitability

This is not a remote code execution or privilege escalation vulnerability. Exploitation does not require special network access or crafted packets; the vulnerability triggers naturally under legitimate heavy traffic conditions. An attacker cannot directly trigger the stall from outside, but an authenticated user or operator who can generate sustained high-volume traffic to a WireGuard peer may increase the probability of triggering the condition. The practical exploitability is low for weaponization but high as a denial-of-service vector if an attacker controls one endpoint of a WireGuard tunnel and deliberately floods traffic patterns that induce the race condition.

Remediation

The Linux kernel community has reverted the problematic threaded NAPI change. Organizations should apply kernel updates that include this revert. Verify against your Linux distribution's security advisory for the specific patched kernel version for your branch (v5.15, v6.1, or others in the affected range). Interim mitigation: disable threaded NAPI for WireGuard if possible via kernel boot parameters or module options, though this may impact performance. Upgrade to v6.6 stable or newer if feasible, as this version does not exhibit the issue. For Kubernetes operators, consider temporarily suspending WireGuard-based pod encryption until patched kernels are deployed, or isolating the affected nodes.

Patch guidance

Apply kernel security updates provided by your Linux distribution for the affected stable branches (v5.15-stable and v6.1-stable). The patch reverts commit db9ae3b6b43c79b1ba87eea849fd65efa05b4b2e. Check your vendor's security advisory (Red Hat, Canonical, SUSE, etc.) for the specific kernel version that includes this revert. Test the patched kernel in a non-production environment first, particularly on systems using WireGuard with heavy traffic loads. After patching, monitor for any recovery of previously stalled connections; affected peers may require manual intervention (interface reset or node reboot) if they entered the stuck state before patching. Document the kernel version in your deployment to prevent regression if future kernel updates occur.

Detection guidance

Monitor WireGuard interfaces for asymmetric behavior: track received vs. processed packets per peer using wg show or netlink interfaces. Alert on situations where a specific peer's rx_queue depth approaches or reaches 1024 queued packets, or where received packet count increases but processed count stalls. Use bpftrace scripts to instrument wg_prev_queue_enqueue (watch for failures), wg_packet_rx_poll (watch for missing calls on a peer), and wg_queue_enqueue_per_peer_rx to detect out-of-order packet state transitions. Enable kernel debug logging for WireGuard if available. In Kubernetes environments, correlate pod-to-pod connectivity timeouts with specific node pairs and check corresponding WireGuard peer status. Cross-reference timing with system load metrics to identify heavy-load triggers.

Why prioritize this

A CVSS 7.5 HIGH vulnerability causing confirmed production outages in Kubernetes clusters warrants immediate attention despite not being remotely exploitable as a traditional code execution issue. The practical impact—complete traffic loss to a peer with no automatic recovery—meets the threshold for critical severity in cloud-native environments. The intermittent nature and lack of standard alerting (CPU/memory appear normal) increase the incident response burden. The fix is a revert of a recent change, suggesting low risk of introducing new issues with the patch. This should be prioritized for kernel updates within the same SLA as high-severity patches in affected deployments.

Risk score, explained

The CVSS 7.5 score reflects a network-accessible denial of service with high impact (complete traffic loss) but no confidentiality or integrity impact and no privilege escalation. The score appropriately captures the severity from an availability perspective. However, in practical terms, the risk is elevated for Kubernetes operators where east-west traffic encryption is critical; organizations relying on WireGuard for cluster security should treat this as equivalent to a 8.0+ severity issue operationally. The lack of KEV status (no active in-the-wild exploitation documented) slightly mitigates the score, but the vulnerability's consistency and reproducibility under known conditions (heavy load on affected kernels) argues for aggressive patching.

Frequently asked questions