CVE-2026-52945

Linux kernel içerisinde aşağıdaki güvenlik açığı giderilmiştir: Revert "wireguard: device: enable threaded NAPI" Bu işlem, upstream tarafındaki commit db9ae3b6b43c79b1ba87eea849fd65efa05b4b2e olan 933466fc50a8e4eb167acbd0d8ec96a078462e9c numaralı commit işlemini geri alır. k8s Pod E/W trafiğinin belirli eş düğümlere iletilmesi için alt katmanda şifreleme amacıyla WireGuard kullanan Cilium ile birlikte, üretim ortamındaki kullanıcılardan bağımsız üç rapor alınmış ve trafiğin tamamen durduğu bildirilmiştir. Durum şu şekilde görünmektedir: - Çok nadir olarak ancak ağır ağ yükü altında rastgele zamanlarda meydana gelir. - Sorun tetiklendiğinde, ilgili WireGuard eşi (peer) için şifre çözme tarafı tamamen durur; diğer eşler düzgün çalışmaya devam eder. Duraksama, söz konusu WireGuard eşine yönelik yeni başlatılan bağlantılar için de gerçekleşir. - Sadece şifre çözme tarafı etkilenir, şifreleme tarafı asla etkilenmez. - Tetiklendikten sonra sistem asla kendiliğinden düzelmez ve bu durumda kalır; düğüm üzerindeki CPU/bellek kullanımı normal görünür, herhangi bir sızıntı, yoğun döngü veya çökme yoktur. - Etkilenen sistemdeki bpftrace, wg_prev_queue_enqueue fonksiyonunun başarısız olduğunu, dolayısıyla eşin rx_queue yapısı için MAX_QUEUED_PACKETS (1024 skb!) sınırına ulaşıldığını göstermektedir. - Ayrıca bpftrace, o eş için bu duruma ulaşıldıktan sonra wg_packet_rx_poll fonksiyonunun bir daha asla çağrılmadığını göstermektedir. Diğer eşler için wg_packet_rx_poll normal şekilde çağrılmaktadır. - Commit db9ae3b ("wireguard: device: enable threaded NAPI"), WireGuard'ı varsayılan olarak threaded NAPI moduna geçirmiştir. Sorunu tetiklemek için varsayılan ayarlar değiştirilmemiş ve CPU hotplugging işlemi gerçekleşmemiştir (yani 5bd8de2 ("wireguard: queueing: always return valid online CPU in wg_cpumask_choose_online()")). - Sorun, v5.15 ve v6.1 kararlı çekirdeklerinde gözlemlenmiştir. v5.10 kararlı sürümünün sorunsuz çalıştığı bildirilmiş ve v6.6 kararlı sürümü hakkında da herhangi bir rapor gelmemiştir ([0]'da konuyla ilgili bazı tartışmalar mevcuttur). - WireGuard sürücüsünde, v5.10 kararlı sürümü ile v5.15 kararlı sürümü arasındaki tek temel fark, varsayılan olarak threaded NAPI'ye geçiş yapılmış olmasıdır. [0] https://lore.kernel.org/netdev/CA+wXwBTT74RErDGAnj98PqS=wvdh8eM1pi4q6tTdExtjnokKqA@mail.gmail.com/ Problemin detayları: 1) Şifre çözme için gelen skb'ler, wg_packet_consume_data içerisindeki wg_queue_enqueue_per_device_and_peer aracılığıyla peer->rx_queue kuyruğuna eklenir. 2) İlgili fonksiyon, yalnızca wg_prev_queue_enqueue üzerinden atomik bir sayaçla takip edilen MAX_QUEUED_PACKETS (1024) sınırı aşılmadığında skb'yi MPSC eş kuyruğuna taşır. 3) Kuyruğa ekleme başarılı olduğunda, skb aynı zamanda cihaz kuyruğuna da eklenir, round-robin yöntemiyle sıradaki çevrimiçi CPU seçilir ve şifre çözme işleyicisi (decryption worker) zamanlanır. 4) Zamanlanan wg_packet_decrypt_worker, bunları kuyruktan alır, paketlerin şifresini çözer ve işlem tamamlandığında wg_queue_enqueue_per_peer_rx fonksiyonunu çağırır. 5) Bu fonksiyon, başarı durumunda durumu PACKET_STATE_CRYPTED olarak günceller ve her peer->napi örneği üzerinde napi_schedule fonksiyonunu çağırır. 6) Ardından NAPI, wg_packet_rx_poll aracılığıyla sorgulama yapar. wg_prev_queue_peek, peer->rx_queue yapısını kontrol eder. Eğer queue->peeked skb henüz önbelleğe alınmamışsa wg_prev_queue_dequeue işlemini gerçekleştirir, aksi takdirde mevcut olanı döndürür. (wg_prev_queue_drop_peeked daha sonra önbelleği temizler.) 7) Sıralama açısından bakıldığında, peer->rx_queue içindeki skb'ler sıralıdır; ancak global sıralama perspektifinden, CPU başına çalışan işleyici iş parçacıklarına sahip olan cihaz kuyruğu, şifre çözmeyi bitirebilir ve skb PACKET_STATE_CRYPTED sinyalini sıra dışı (out of order) şekilde verebilir. 8) Sistem baskı altındayken, gelen ilk paketin şifre çözme işleyicisinin zamanlanmasını beklediği süre uzadığında böyle bir durum gözlemlenebilir. 9) Bu sırada diğer CPU'lar şifre çözme işlemini tamamlar ve napi_schedule fonksiyonunu çağırır. 10) Şimdi wg_packet_rx_poll, peer->rx_queue içerisindeki ilk sıralı skb'yi alır ve durumunun hala PACKET_STATE_UNCRYPTED olduğunu görür. Bunun üzerine NAPI sorgulama rutini çıkar...