CVE-2026-74523 in Linux
Zusammenfassung
von VulDB • 15.08.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
qede: Synchronisierung von UDP-Tunnel-Ports außerhalb der qede_Sperre im Wiederherstellungspfad
Ein TX-Zeitüberschreitungsfehler (TX timeout) bei einer qede-NIC, für die VXLAN/GENEVE-Tunnelports konfiguriert sind, führt dazu, dass die rtnetlink-Control-Ebene des gesamten Systems blockiert wird:
NETDEV WATCHDOG: ens6f1 (qede): Transmit-Queue 2 hat nach 10226 ms das Zeitlimit überschritten [qede_tx_timeout:586(ens6f1)] TX-Zeitüberschreitung bei Queue 2!
[qede_recovery_handler:2665(ens6f0)] Starten eines Wiederherstellungsprozesses
Der Wiederherstellungspfad gerät in einen Deadlock bezüglich der eigenen Mutex des Treibers:
qede_sp_task rtnl_lock() mutex_lock(&edev->qede_lock) <- belegt 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) <- gleiche Aufgabe: Deadlock
Die Mutex ist nicht rekursiv, sodass der kworker sich selbst blockiert, während rtnl_lock gehalten wird, und keine der Sperren wird jemals freigegeben. Jede Aufgabe, die danach rtnl_lock() aufruft (ip, ovs-vswitchd, lldpad, IPv6-addrconf, sshd), blockiert für immer, obwohl der Knoten weiterhin auf Ping-Anfragen antwortet. In einem vmcore eines betroffenen Produktionsknotens decodiert rtnl_mutex.owner zu dem genau jenen kworker, der an der innersten mutex_lock()-Anweisung oben blockiert ist.
Die Tunnelports werden von qede_sp_task() erneut synchronisiert, nachdem die interne Sperre aufgehoben wurde, wobei weiterhin rtnl_lock gehalten wird, wie es die udp_tunnel-API erfordert. Dies entspricht dem Verhalten von qede_open(), das udp_tunnel_nic_reset_ntf() unter rtnl ohne die interne Sperre aufruft.
qede_recovery_handler() gibt nun zurück, ob ein geöffnetes Gerät erfolgreich neu geladen wurde, und der Aufrufer synchronisiert die Ports nur in diesem Fall erneut. Dies erhält die alte Bedingung genau bei: Ein Gerät, das heruntergefahren war oder dessen Wiederherstellung fehlgeschlagen ist, gibt false zurück, da diese Pfade den udp_tunnel_nic_reset_ntf()-Aufruf zuvor ebenfalls nie erreicht haben.
Dies war der einzige Nutzer der qede_lock()/qede_unlock()-Hilfsfunktionen, daher werden sie entfernt.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.