{ "schema_version": "1.6.1", "id": "RPI-CVE-2026-74523", "modified": "2026-10-09T11:39:44Z", "upstream": [ "CVE-2026-74523" ], "published": "2026-08-15T12:28:42Z", "summary": "qede: sync udp_tunnel ports outside qede_lock in the recovery path", "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'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.", "severity": [ { "type": "CVSS_V3", "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H" } ], "affected": [ { "package": { "ecosystem": "Raspberry Pi OS:12", "name": "linux" }, "versions": [ "1:6.1.47-1+rpt4" ], "ecosystem_specific": { "binaries": [ { "binary_name": "linux-image-6.1.0-rpi3-rpi-2712", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-v6", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-v7", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-v7l", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-v8", "binary_version": "1:6.1.47-1+rpt4" } ] }, "database_specific": { "per_version": { "1:6.1.47-1+rpt4": { "linux_commit": "655fc658a15ae7a6f37103754adb39ba52a9a14e", "upstream_version": "6.1.47", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.1.183", "compiled_filter": false } } } } ], "references": [ { "type": "ADVISORY", "url": "https://www.cve.org/CVERecord?id=CVE-2026-74523" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/19e505ee8bb9e0f0355eda9e9f614fb25fed0070" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/c4c1e5d6bc2b900b2328d6fff93dc8146b858d69" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/8e1bdf57de91247e57816482966265ada573cc74" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/e382a4efeeae6555b95d9ff336cf3094ee7d336b" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/4626df3f63c9185efba5750fe76ac01ab3351bae" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/e51becb8f3377a377171ed5bf0082b96e22e6292" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/6f1ef8170d3d8ad9319aa01347945dcdf5cc4f27" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/451c9075d6c53f2438d110addbeeeea6fac18567" } ], "database_specific": { "source": "https://git.kernel.org/pub/scm/linux/security/vulns.git", "upstream_modified": "2026-08-19T16:47:12Z", "severity": { "source": "kernel CNA", "cvss_v3_score": 7.5, "cvss_v3_severity": "High", "scenario": "AV:N - The bug is reached from the qede NIC firmware error-recovery path triggered by network-driven faults (e.g., TX queue watchdog timeout on traffic-bearing queues); remote packets to an internet-facing qede host can induce recovery without local syscall access.\nAC:L - Once qede recovery runs on an interface with VXLAN/GENEVE ports registered, the nested qede_lock while rtnl_lock is held deadlocks deterministically; attackers can repeatedly apply traffic/load patterns to provoke TX timeout and firmware ERROR_RECOVERY.\nPR:N - Exploitation requires only the ability to send network traffic that provokes NIC recovery on a target that already has VXLAN/GENEVE offloads configured (normal on cloud/DC qede nodes); no attacker privileges or rtnetlink configuration are needed.\nUI:N - No victim interaction is required beyond routine use of a server whose qede uplink already runs overlay networking; the attacker does not need the victim to mount, open, or approve anything at exploit time.\nS:U - Impact is a kernel networking control-plane deadlock within the same host/kernel trust boundary; it does not cross VM, container, or IOMMU security domains to affect other authorities.\nC:N - This is a locking deadlock with no memory corruption, out-of-bounds access, use-after-free, or information disclosure; only mutex/RTNL state is wedged.\nI:N - The flaw does not modify data or achieve code execution; it only blocks threads waiting on rtnl_lock/qede_lock without altering memory contents or kernel objects beyond stalled lock state.\nA:H - The deadlock holds rtnl_lock indefinitely, freezing system-wide network reconfiguration and management (ip, ovs-vswitchd, sshd addr setup) until reboot; per CVSS guidance, kernel deadlocks that deny critical availability are rated High." } } }