{"id":7528,"date":"2026-09-04T18:49:35","date_gmt":"2026-09-04T10:49:35","guid":{"rendered":"https:\/\/www.54iter.cn\/?vuln=cve-2026-74523"},"modified":"2026-09-04T18:49:35","modified_gmt":"2026-09-04T10:49:35","slug":"cve-2026-74523","status":"publish","type":"vuln","link":"https:\/\/www.54iter.cn\/?vuln=cve-2026-74523","title":{"rendered":"CVE-2026-74523 [HIGH] &#8211; In the Linux kernel, the following vulnerability has been resolved:\n\nqede: sync udp_tunnel"},"content":{"rendered":"<p>In the Linux kernel, the following vulnerability has been resolved:<\/p>\n<p>qede: sync udp_tunnel ports outside qede_lock in the recovery path<\/p>\n<p>A TX timeout on a qede NIC that has VXLAN\/GENEVE tunnel ports<br \/>\nconfigured wedges the rtnetlink control plane of the whole machine:<\/p>\n<p>  NETDEV WATCHDOG: ens6f1 (qede): transmit queue 2 timed out 10226 ms<br \/>\n  [qede_tx_timeout:586(ens6f1)]TX timeout on queue 2!<br \/>\n  [qede_recovery_handler:2665(ens6f0)]Starting a recovery process<\/p>\n<p>The recovery path deadlocks on the driver&#8217;s own mutex:<\/p>\n<p>  qede_sp_task<br \/>\n   rtnl_lock()<br \/>\n   mutex_lock(&amp;edev-&gt;qede_lock)        sync_table == qede_udp_tunnel_sync<br \/>\n       mutex_lock(&amp;edev-&gt;qede_lock)    &lt;- same task: deadlock<\/p>\n<p>The mutex is not recursive, so the kworker blocks on itself with<br \/>\nrtnl_lock held, and neither lock is ever released. Every task that<br \/>\ncalls rtnl_lock() afterwards (ip, ovs-vswitchd, lldpad, IPv6<br \/>\naddrconf, sshd) blocks forever while the node still answers ping.<br \/>\nIn a vmcore from an affected production node rtnl_mutex.owner<br \/>\ndecodes to the very kworker blocked at the innermost mutex_lock()<br \/>\nabove.<\/p>\n<p>Re-sync the tunnel ports from qede_sp_task() after the internal lock<br \/>\nis dropped, still under rtnl_lock as the udp_tunnel API requires.<br \/>\nThis mirrors qede_open(), which calls udp_tunnel_nic_reset_ntf()<br \/>\nunder rtnl without the internal lock.<\/p>\n<p>qede_recovery_handler() now returns whether it has successfully<br \/>\nreloaded an open device, and the caller re-syncs the ports only in<br \/>\nthat case. This keeps the old gating exactly: a device that was down<br \/>\nor a failed recovery returns false, as those paths never reached the<br \/>\nudp_tunnel_nic_reset_ntf() call before either.<\/p>\n<p>This was the only user of the qede_lock()\/qede_unlock() helpers, so<br \/>\nremove them.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>In the Linux kernel, the following vulnerability has been resolved:<\/p>\n<p>qede: sync udp_tunnel ports outside qede_lock in the recovery path<\/p>\n<p>A TX timeout on a qede NIC that has VXLAN\/GENEVE tunnel ports<br \/>\nc<\/p>\n","protected":false},"template":"","meta":[],"categories":[],"tags":[],"class_list":["post-7528","vuln","type-vuln","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln\/7528","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln"}],"about":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/types\/vuln"}],"wp:attachment":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=7528"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=7528"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=7528"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}