CVE-2026-52945

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&amp;#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-&gt;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-&gt;napi instance.<br /> 6) NAPI then polls via wg_packet_rx_poll. wg_prev_queue_peek checks<br /> on the peer-&gt;rx_queue. It will wg_prev_queue_dequeue if the<br /> queue-&gt;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-&gt;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-&gt;rx_queue and sees that its state is still<br /> PACKET_STATE_UNCRYPTED. The NAPI poll routine then exits e<br /> ---truncated---