CVE-2026-74523

CVE CVE-2026-74523EUVD EUVD-2026-59716Veröffentlicht 2026-08-15T12:27:40.000ZZuletzt geändert 2026-08-19T16:38:27.000ZCVSS 7.5

Was das Advisory beschreibt

In the Linux kernel, the following vulnerability has been resolved: qede: sync udp_tunnel ports outside qede_lock in the recovery path A TX timeout on a qede NIC that has VXLAN/GENEVE tunnel ports configured wedges the rtnetlink control plane of the whole machine: 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 The recovery path deadlocks on the driver's own mutex: qede_sp_task rtnl_lock() mutex_lock(&edev->qede_lock) <- taken 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) <- same task: deadlock The mutex is not recursive, so the kworker blocks on itself with rtnl_lock held, and neither lock is ever released. Every task that calls rtnl_lock() afterwards (ip, ovs-vswitchd, lldpad, IPv6 addrconf, sshd) blocks forever while the node still answers ping. In a vmcore from an affected production node rtnl_mutex.owner decodes to the very kworker blocked at the innermost mutex_lock() above. Re-sync the tunnel ports from qede_sp_task() after the internal lock is dropped, still under rtnl_lock as the udp_tunnel API requires. This mirrors qede_open(), which calls udp_tunnel_nic_reset_ntf() under rtnl without the internal lock. qede_recovery_handler() now returns whether it has successfully reloaded an open device, and the caller re-syncs the ports only in that case. This keeps the old gating exactly: a device that was down or a failed recovery returns false, as those paths never reached the udp_tunnel_nic_reset_ntf() call before either. This was the only user of the qede_lock()/qede_unlock() helpers, so remove them.

Quelle: EUVD (ENISA), im Wortlaut der Meldung.

Produkte, die das Advisory nennt

Diese Angaben stammen aus der Meldung selbst, nicht aus einer Prüfung durch uns.

• Linux — Linux 8cd160a29415f1789d473b1dc07fcc9d02a02b87 <451c9075d6c53f2438d110addbeeeea6fac18567; 5.9; patch: 7.1.8; 8cd160a29415f1789d473b1dc07fcc9d02a02b87 <6f1ef8170d3d8ad9319aa01347945dcdf5cc4f27; patch: 5.15.216; patch: 6.6.151; 8cd160a29415f1789d473b1dc07fcc9d02a02b87 <e51becb8f3377a377171ed5bf0082b96e22e6292; patch: 5.10.265; 8cd160a29415f1789d473b1dc07fcc9d02a02b87 <4626df3f63c9185efba5750fe76ac01ab3351bae; patch: 0; 8cd160a29415f1789d473b1dc07fcc9d02a02b87 <8e1bdf57de91247e57816482966265ada573cc74; patch: 6.18.44; 8cd160a29415f1789d473b1dc07fcc9d02a02b87 <c4c1e5d6bc2b900b2328d6fff93dc8146b858d69; 8cd160a29415f1789d473b1dc07fcc9d02a02b87 <19e505ee8bb9e0f0355eda9e9f614fb25fed0070; patch: 7.2; patch: 6.1.183; 8cd160a29415f1789d473b1dc07fcc9d02a02b87 <e382a4efeeae6555b95d9ff336cf3094ee7d336b; patch: 6.12.103

Die genannten Versionen sind die Angabe der Meldung. Patchlage vergleicht keine Versionsnummern und leitet aus ihnen keine Aussage ab — welche Version installiert ist, muss ein Mensch nachsehen.

Im Produktkatalog geführt

Für diese Produkte kann ein Bestand in Patchlage erfasst werden. Ein Advisory dazu erscheint am Morgen danach im Lagebericht.

• Linux — Linux

Patchlage meldet Treffer und Verdachtsfälle. Zu allem anderen sagt dieses System nichts — weder diese Seite noch der Lagebericht behauptet je, dass ein Bestand sicher ist.