CVE-2026-52945
Publication date:
24/06/2026
In the Linux kernel, the following vulnerability has been resolved:<br />
<br />
Revert "wireguard: device: enable threaded NAPI"<br />
<br />
This reverts commit 933466fc50a8e4eb167acbd0d8ec96a078462e9c which is<br />
commit db9ae3b6b43c79b1ba87eea849fd65efa05b4b2e upstream.<br />
<br />
We have had three independent production user reports in combination<br />
with Cilium utilizing WireGuard as encryption underneath that k8s Pod<br />
E/W traffic to certain peer nodes fully stalled. The situation appears<br />
as follows:<br />
<br />
- Occurs very rarely but at random times under heavy networking load.<br />
- Once the issue triggers the decryption side stops working completely<br />
for that WireGuard peer, other peers keep working fine. The stall<br />
happens also for newly initiated connections towards that particular<br />
WireGuard peer.<br />
- Only the decryption side is affected, never the encryption side.<br />
- Once it triggers, it never recovers and remains in this state,<br />
the CPU/mem on that node looks normal, no leak, busy loop or crash.<br />
- bpftrace on the affected system shows that wg_prev_queue_enqueue<br />
fails, thus the MAX_QUEUED_PACKETS (1024 skbs!) for the peer&#39;s<br />
rx_queue is reached.<br />
- Also, bpftrace shows that wg_packet_rx_poll for that peer is never<br />
called again after reaching this state for that peer. For other<br />
peers wg_packet_rx_poll does get called normally.<br />
- Commit db9ae3b ("wireguard: device: enable threaded NAPI")<br />
switched WireGuard to threaded NAPI by default. The default has<br />
not been changed for triggering the issue, neither did CPU<br />
hotplugging occur (i.e. 5bd8de2 ("wireguard: queueing: always<br />
return valid online CPU in wg_cpumask_choose_online()")).<br />
- The issue has been observed with stable kernels of v5.15 as well as<br />
v6.1. It was reported to us that v5.10 stable is working fine, and<br />
no report on v6.6 stable either (somewhat related discussion in [0]<br />
though).<br />
- In the WireGuard driver the only material difference between v5.10<br />
stable and v5.15 stable is the switch to threaded NAPI by default.<br />
<br />
[0] https://lore.kernel.org/netdev/CA+wXwBTT74RErDGAnj98PqS=wvdh8eM1pi4q6tTdExtjnokKqA@mail.gmail.com/<br />
<br />
Breakdown of the problem:<br />
<br />
1) skbs arriving for decryption are enqueued to the peer->rx_queue in<br />
wg_packet_consume_data via wg_queue_enqueue_per_device_and_peer.<br />
2) The latter only moves the skb into the MPSC peer queue if it does<br />
not surpass MAX_QUEUED_PACKETS (1024) which is kept track in an<br />
atomic counter via wg_prev_queue_enqueue.<br />
3) In case enqueueing was successful, the skb is also queued up<br />
in the device queue, round-robin picks a next online CPU, and<br />
schedules the decryption worker.<br />
4) The wg_packet_decrypt_worker, once scheduled, picks these up<br />
from the queue, decrypts the packets and once done calls into<br />
wg_queue_enqueue_per_peer_rx.<br />
5) The latter updates the state to PACKET_STATE_CRYPTED on success<br />
and calls napi_schedule on the per peer->napi instance.<br />
6) NAPI then polls via wg_packet_rx_poll. wg_prev_queue_peek checks<br />
on the peer->rx_queue. It will wg_prev_queue_dequeue if the<br />
queue->peeked skb was not cached yet, or just return the latter<br />
otherwise. (wg_prev_queue_drop_peeked later clears the cache.)<br />
7) From an ordering perspective, the peer->rx_queue has skbs in order<br />
while the device queue with the per-CPU worker threads from a<br />
global ordering PoV can finish the decryption and signal the skb<br />
PACKET_STATE_CRYPTED out of order.<br />
8) A situation can be observed that the first packet coming in will<br />
be stuck waiting for the decryption worker to be scheduled for<br />
a longer time when the system is under pressure.<br />
9) While this is the case, the other CPUs in the meantime finish<br />
decryption and call into napi_schedule.<br />
10) Now in wg_packet_rx_poll it picks up the first in-order skb<br />
from the peer->rx_queue and sees that its state is still<br />
PACKET_STATE_UNCRYPTED. The NAPI poll routine then exits e<br />
---truncated---
Severity CVSS v4.0: Pending analysis
Last modification:
14/07/2026
