The kernel change that enables threaded NAPI in the WireGuard driver has introduced a race in the decryption workflow. When decryption stalls occur it causes the RX queue for the affected peer to saturate, after which no further packets for that peer are processed. The stall persists indefinitely, affecting only the decryption side of the connection while encryption continues normally. This loss of connectivity can be interpreted as a denial of service on the network layer, as traffic to the peer becomes completely blocked. No crash or memory leak accompanies the condition, but the network stack becomes unresponsive for that specific WireGuard endpoint.

Linux kernel versions 5.15 and 6.1 stable are impacted when the threaded‑NAPI feature is enabled. Versions 5.10 stable and 6.6 stable appear to be unaffected, indicating the problem was present in the 5.15/6.1 stable branches but not in earlier or later stable releases.

The issue is unlikely to lead to arbitrary code execution or privilege escalation; the impact is limited to availability of network traffic for the affected peer. The exploit requires that traffic is routed through a WireGuard interface on a node running one of the vulnerable kernel versions and that the system experiences heavy networking load. The lack of a publicly available CVSS score makes the severity uncertain, but the fact that the condition never recovers and can be triggered under normal operational loads increases the practical risk. The vulnerability is not documented in the CISA KEV catalogue and its EPSS score is not available, which suggests that broad exploitation is not yet observed but the risk remains significant for environments relying on WireGuard for Pod-to-Pod communication in Kubernetes clusters.