CVE-2026-74523

Linux kernel içerisinde aşağıdaki güvenlik açığı giderilmiştir: qede: kurtarma yolunda udp_tunnel portlarını qede_lock dışında senkronize et VXLAN/GENEVE tünel portları yapılandırılmış bir qede NIC üzerindeki bir TX zaman aşımı, tüm makinenin rtnetlink kontrol düzlemini kilitler: NETDEV WATCHDOG: ens6f1 (qede): transmit queue 2 timed out 10226 ms [qede_tx_timeout:586(ens6f1)]TX timeout on queue 2! [qede_recovery_handler:2665(ens6f0)]Starting a recovery process Kurtarma yolu, sürücünün kendi mutex yapısında ölü kilitlemeye (deadlock) neden olur: qede_sp_task rtnl_lock() mutex_lock(&edev->qede_lock) <- alındı qede_recovery_handler qede_load udp_tunnel_nic_reset_ntf __udp_tunnel_nic_device_sync info->sync_table == qede_udp_tunnel_sync mutex_lock(&edev->qede_lock) <- aynı görev: ölü kilitleme Mutex rekürsif değildir, bu nedenle kworker, rtnl_lock tutulurken kendisini engeller ve hiçbir kilit serbest bırakılmaz. Bundan sonra rtnl_lock() çağıran her görev (ip, ovs-vswitchd, lldpad, IPv6 addrconf, sshd), düğüm hala ping yanıtı verirken sonsuza kadar engellenir. Etkilenen bir üretim düğümünden alınan vmcore dosyasında, rtnl_mutex.owner değeri yukarıdaki en içteki mutex_lock() işleminde engellenen kworker'a karşılık gelmektedir. Tünel portlarını, udp_tunnel API'sinin gerektirdiği şekilde hala rtnl_lock altındayken ancak dahili kilit bırakıldıktan sonra qede_sp_task() üzerinden yeniden senkronize edin. Bu durum, udp_tunnel_nic_reset_ntf() fonksiyonunu dahili kilit olmadan rtnl altında çağıran qede_open() ile benzerlik gösterir. qede_recovery_handler() artık açık bir aygıtın başarıyla yeniden yüklenip yüklenmediğini döndürmekte ve çağırıcı, portları yalnızca bu durumda yeniden senkronize etmektedir. Bu, eski denetimi aynen korur: kapalı olan bir aygıt veya başarısız bir kurtarma işlemi false döndürür; çünkü bu yollar daha önce de udp_tunnel_nic_reset_ntf() çağrısına hiç ulaşmamıştı. Bu, qede_lock()/qede_unlock() yardımcılarının tek kullanıcısıydı, bu nedenle bunlar kaldırılmıştır.