CVE-2026-74523 in Linux
Riassunto
di VulDB • 15/08/2026
Nel kernel Linux è stata risolta la seguente vulnerabilità:
qede: sincronizzare le porte udp_tunnel al di fuori di qede_lock nel percorso di recupero
Un timeout TX su una scheda di rete (NIC) qede con porte del tunnel VXLAN/GENEVE configurate blocca il piano di controllo rtnetlink dell'intera macchina:
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
Il percorso di recupero va in deadlock sul mutex proprietario del driver:
qede_sp_task rtnl_lock() mutex_lock(&edev->qede_lock) <- acquisito 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) <- stesso task: deadlock
Il mutex non è ricorsivo, quindi il kworker si blocca su se stesso con rtnl_lock mantenuto e nessuno dei due lock viene mai rilasciato. Ogni task che chiama successivamente rtnl_lock() (ip, ovs-vswitchd, lldpad, addrconf IPv6, sshd) rimane bloccato indefinitamente mentre il nodo continua a rispondere ai ping. In un vmcore di un nodo di produzione interessato, rtnl_mutex.owner decodifica esattamente nel kworker bloccato all'interno della chiamata mutex_lock() più interna sopra indicata.
Risincronizzare le porte del tunnel da qede_sp_task() dopo aver rilasciato il lock interno, mantenendo comunque rtnl_lock come richiesto dall'API udp_tunnel. Questo comportamento rispecchia quello di qede_open(), che chiama udp_tunnel_nic_reset_ntf() sotto rtnl senza il lock interno.
qede_recovery_handler() ora restituisce se ha ricaricato con successo un dispositivo aperto e il chiamante risincronizza le porte solo in quel caso. Ciò mantiene la logica di controllo precedente: un dispositivo che era down o per cui il recupero è fallito restituisce false, poiché quei percorsi non raggiungevano mai prima la chiamata udp_tunnel_nic_reset_ntf().
Questo era l'unico utilizzatore delle helper qede_lock()/qede_unlock(), quindi vengono rimosse.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.