{"cve":"CVE-2026-74523","nvd":{"published":"2026-08-15T13:17:57.543","modified":"2026-10-16T20:17:34.927","status":"Received","description":"In the Linux kernel, the following vulnerability has been resolved:\n\nqede: sync udp_tunnel ports outside qede_lock in the recovery path\n\nA TX timeout on a qede NIC that has VXLAN/GENEVE tunnel ports\nconfigured wedges the rtnetlink control plane of the whole machine:\n\n  NETDEV WATCHDOG: ens6f1 (qede): transmit queue 2 timed out 10226 ms\n  [qede_tx_timeout:586(ens6f1)]TX timeout on queue 2!\n  [qede_recovery_handler:2665(ens6f0)]Starting a recovery process\n\nThe recovery path deadlocks on the driver's own mutex:\n\n  qede_sp_task\n   rtnl_lock()\n   mutex_lock(&edev->qede_lock)        <- taken\n   qede_recovery_handler\n    qede_load\n    udp_tunnel_nic_reset_ntf\n     __udp_tunnel_nic_device_sync\n      info->sync_table == qede_udp_tunnel_sync\n       mutex_lock(&edev->qede_lock)    <- same task: deadlock\n\nThe mutex is not recursive, so the kworker blocks on itself with\nrtnl_lock held, and neither lock is ever released. Every task that\ncalls rtnl_lock() afterwards (ip, ovs-vswitchd, lldpad, IPv6\naddrconf, sshd) blocks forever while the node still answers ping.\nIn a vmcore from an affected production node rtnl_mutex.owner\ndecodes to the very kworker blocked at the innermost mutex_lock()\nabove.\n\nRe-sync the tunnel ports from qede_sp_task() after the internal lock\nis dropped, still under rtnl_lock as the udp_tunnel API requires.\nThis mirrors qede_open(), which calls udp_tunnel_nic_reset_ntf()\nunder rtnl without the internal lock.\n\nqede_recovery_handler() now returns whether it has successfully\nreloaded an open device, and the caller re-syncs the ports only in\nthat case. This keeps the old gating exactly: a device that was down\nor a failed recovery returns false, as those paths never reached the\nudp_tunnel_nic_reset_ntf() call before either.\n\nThis was the only user of the qede_lock()/qede_unlock() helpers, so\nremove them.","cvss_v4":null,"cvss_v3":{"version":"3.1","vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H","score":7.5},"cwes":[],"references":["https://git.kernel.org/stable/c/19e505ee8bb9e0f0355eda9e9f614fb25fed0070","https://git.kernel.org/stable/c/451c9075d6c53f2438d110addbeeeea6fac18567","https://git.kernel.org/stable/c/4626df3f63c9185efba5750fe76ac01ab3351bae","https://git.kernel.org/stable/c/6f1ef8170d3d8ad9319aa01347945dcdf5cc4f27","https://git.kernel.org/stable/c/8e1bdf57de91247e57816482966265ada573cc74"],"products":[],"source":"nvd","synced_at":"2026-10-19T22:49:10.689564601+00:00"},"epss":{"cve":"CVE-2026-74523","score":0.00501,"percentile":0.42627,"date":"2026-10-25"},"kev":null,"osv":[],"attribution":["This product uses the NVD API but is not endorsed or certified by the NVD.","EPSS scores: FIRST Exploit Prediction Scoring System, https://www.first.org/epss","Known exploited vulnerabilities: CISA Known Exploited Vulnerabilities Catalog, https://www.cisa.gov/known-exploited-vulnerabilities-catalog","Package advisories: OSV (https://osv.dev), from the GitHub Advisory Database, PyPA, Go, RustSec and other ecosystem databases, under CC-BY 4.0 or CC0","CVE records: the CVE Program's CVE List (https://www.cve.org), under its terms of use (https://www.cve.org/Legal/TermsOfUse). CVE is a registered trademark of The MITRE Corporation; this product is not affiliated with the CVE Program."]}