GHSA-WF9X-RW9Q-X6MF
Vulnerability from github – Published: 2026-08-15 15:30 – Updated: 2026-08-19 18:32In 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.
{
"affected": [],
"aliases": [
"CVE-2026-74523"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-15T13:17:57Z",
"severity": "HIGH"
},
"details": "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\u0027s own mutex:\n\n qede_sp_task\n rtnl_lock()\n mutex_lock(\u0026edev-\u003eqede_lock) \u003c- taken\n qede_recovery_handler\n qede_load\n udp_tunnel_nic_reset_ntf\n __udp_tunnel_nic_device_sync\n info-\u003esync_table == qede_udp_tunnel_sync\n mutex_lock(\u0026edev-\u003eqede_lock) \u003c- 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.",
"id": "GHSA-wf9x-rw9q-x6mf",
"modified": "2026-08-19T18:32:30Z",
"published": "2026-08-15T15:30:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-74523"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/19e505ee8bb9e0f0355eda9e9f614fb25fed0070"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/451c9075d6c53f2438d110addbeeeea6fac18567"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4626df3f63c9185efba5750fe76ac01ab3351bae"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6f1ef8170d3d8ad9319aa01347945dcdf5cc4f27"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8e1bdf57de91247e57816482966265ada573cc74"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c4c1e5d6bc2b900b2328d6fff93dc8146b858d69"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e382a4efeeae6555b95d9ff336cf3094ee7d336b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e51becb8f3377a377171ed5bf0082b96e22e6292"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.