CVE-2026-52945

Linux nüvəsində aşağıdakı zəiflik aradan qaldırılıb: Revert "wireguard: device: enable threaded NAPI" Bu, upstream-də commit db9ae3b6b43c79b1ba87eea849fd65efa05b4b2e olan 933466fc50a8e4eb167acbd0d8ec96a078462e9c commit-ini ləğv edir. k8s Pod E/W trafikinin müəyyən peer nodlarına ötürülməsi üçün alt strukturda şifrələmə kimi WireGuard istifadə edən Cilium ilə birlikdə üç müstəqil istehsalat istifadəçisi tərəfindən həmin trafikin tamamilə dayandığı barədə hesabatlar daxil olmuşdur. Vəziyyət aşağıdakı kimidir: - Çox nadir hallarda, lakin ağır şəbəkə yükü altında təsadüfi vaxtlarda baş verir. - Problem tetikləndikdən sonra dekripsiya tərəfi həmin WireGuard peer-i üçün tamamilə işləməyi dayandırır, digər peer-lər normal şəkildə işləməyə davam edir. Dayanma həmin konkret WireGuard peer-inə doğru yeni başladılmış bağlantılar üçün də baş verir. - Yalnız dekripsiya tərəfi təsirlənir, şifrələmə tərəfi heç vaxt təsirlənmir. - Bir dəfə tetikləndikdən sonra o, heç vaxt bərpa olunmur və bu vəziyyətdə qalır; həmin nodda CPU/mem normal görünür, sızma, sonsuz dövr (busy loop) və ya çöküş yoxdur. - Təsirə məruz qalmış sistemdə bpftrace göstərir ki, wg_prev_queue_enqueue uğursuz olur, beləliklə peer-in rx_queue-su üçün MAX_QUEUED_PACKETS (1024 skb!) limitinə çatılır. - Həmçinin, bpftrace göstərir ki, həmin peer üçün bu vəziyyətə çatdıqdan sonra wg_packet_rx_poll bir daha çağırılmır. Digər peer-lər üçün wg_packet_rx_poll normal şəkildə çağırılır. - Commit db9ae3b ("wireguard: device: enable threaded NAPI") WireGuard-ı standart olaraq threaded NAPI-yə keçirdi. Problemi tetikləmək üçün standart parametrlər dəyişdirilməmişdir, həmçinin CPU hotplugging də baş verməmişdir (məsələn, 5bd8de2 ("wireguard: queueing: always return valid online CPU in wg_cpumask_choose_online()")). - Problem v5.15 və v6.1 stabil nüvələrində müşahidə edilmişdir. Bizə bildirilib ki, v5.10 stabil versiyası normal işləyir və v6.6 stabil versiyası haqqında da heç bir hesabat yoxdur ([0]-da buna dair müəyyən müzakirələr var). - WireGuard drayverində v5.10 stabil və v5.15 stabil versiyaları arasındakı yeganə əhəmiyyətli fərq standart olaraq threaded NAPI-yə keçiddir. [0] https://lore.kernel.org/netdev/CA+wXwBTT74RErDGAnj98PqS=wvdh8eM1pi4q6tTdExtjnokKqA@mail.gmail.com/ Problemin təhlili: 1) Dekripsiya üçün gələn skb-lər wg_packet_consume_data funksiyasında wg_queue_enqueue_per_device_and_peer vasitəsilə peer->rx_queue-ya yerləşdirilir. 2) Sonuncu, yalnız skb MAX_QUEUED_PACKETS (1024) limitini aşmadıqda onu MPSC peer növbəsinə köçürür; bu limit wg_prev_queue_enqueue vasitəsilə atomik sayğacla izlənilir. 3) Yerləşdirmə uğurlu olduqda, skb həmçinin cihaz növbəsinə də yerləşdirilir, round-robin növbəti aktiv CPU-nu seçir və dekripsiya işçisini (worker) planlaşdırır. 4) wg_packet_decrypt_worker planlaşdırıldıqdan sonra bunları növbədən götürür, paketləri dekripsiya edir və tamamlandıqdan sonra wg_queue_enqueue_per_peer_rx funksiyasını çağırır. 5) Sonuncusu, uğur qazanıldıqda vəziyyəti PACKET_STATE_CRYPTED olaraq yeniləyir və hər bir peer->napi instansiyasında napi_schedule funksiyasını çağırır. 6) Daha sonra NAPI wg_packet_rx_poll vasitəsilə sorğu göndərir. wg_prev_queue_peek peer->rx_queue-nu yoxlayır. Əgər queue->peeked skb hələ keşlənməyibsə, wg_prev_queue_dequeue edəcək, əks halda sadəcə sonuncunu qaytaracaq. (wg_prev_queue_drop_peeked daha sonra keşi təmizləyir.) 7) Sıralama baxımından, peer->rx_queue skb-ləri ardıcıllıqla saxlayır, lakin qlobal sıralama nöqteyi-nəzərindən per-CPU işçi axınları olan cihaz növbəsi dekripsiyanı tamamlayıb skb-ni PACKET_STATE_CRYPTED olaraq sıradan kənar siqnal verə bilər. 8) Belə bir vəziyyət müşahidə edilə bilər ki, sistem yüklü olduqda ilk gələn paket dekripsiya işçisinin planlaşdırılmasını daha uzun müddət gözləyib ilişib qalır. 9) Bu baş verdiyi müddətdə, digər CPU-lar bu arada dekripsiyanı tamamlayır və napi_schedule funksiyasını çağırırlar. 10) İndi wg_packet_rx_poll peer->rx_queue-dan birinci ardıcıl skb-ni götürür və onun vəziyyətinin hələ də PACKET_STATE_UNCRYPTED olduğunu görür. NAPI sorğu rutini bundan sonra çıxış edir...