Skip to content
Heist/ feed
Back to feed
HighFix available

qede: sync udp_tunnel ports outside qede_lock in the recovery path

Type: advisorySources: OSV

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

Products
Kernel
Affected versions
Not specified
Fixed versions
5.10.265, 5.15.216, 6.1.183, 6.12.103, 6.18.44, 6.6.151, 7.1.8
CVEs
CVE-2026-74523
Confirmed fixed CVEs
Not specified
Updated in this feed
5 Nov 2026, 04:03 UTC · Revision 1

Source evidence

qede: sync udp_tunnel ports outside qede_lock in the recovery path

core-osv · Original source

Published 15 Aug 2026, 12:27 UTC

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

osv:CVE-2026-74523

Kernel

Fixed versions: 5.10.265, 5.15.216, 6.1.183, 6.6.151, 6.12.103, 6.18.44, 7.1.8

Complete source record
{
  "id": "47183885d319bfb00f6ea10a14eefad30de02adb154eedd9eb3079d35e81e34c",
  "url": "https://osv.dev/vulnerability/CVE-2026-74523",
  "method": "structured",
  "payload": {
    "kind": "advisory",
    "title": "qede: sync udp_tunnel ports outside qede_lock in the recovery path",
    "summary": "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",
    "evidence": "osv:CVE-2026-74523",
    "products": [
      {
        "name": {
          "value": "Kernel",
          "evidence": "/affected/1/package/name"
        },
        "prerequisites": [],
        "fixed_versions": [
          {
            "value": "5.10.265",
            "evidence": "/affected/1/ranges"
          },
          {
            "value": "5.15.216",
            "evidence": "/affected/1/ranges"
          },
          {
            "value": "6.1.183",
            "evidence": "/affected/1/ranges"
          },
          {
            "value": "6.6.151",
            "evidence": "/affected/1/ranges"
          },
          {
            "value": "6.12.103",
            "evidence": "/affected/1/ranges"
          },
          {
            "value": "6.18.44",
            "evidence": "/affected/1/ranges"
          },
          {
            "value": "7.1.8",
            "evidence": "/affected/1/ranges"
          }
        ],
        "affected_versions": []
      }
    ],
    "severity": "high",
    "structured": {
      "id": "CVE-2026-74523",
      "aliases": [
        "CVE-2026-74523"
      ],
      "metrics": [
        {
          "type": "CVSS_V3",
          "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H"
        }
      ],
      "affected": [
        {
          "ranges": [
            {
              "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
              "type": "GIT",
              "events": [
                {
                  "introduced": "8cd160a29415f1789d473b1dc07fcc9d02a02b87"
                },
                {
                  "fixed": "19e505ee8bb9e0f0355eda9e9f614fb25fed0070"
                },
                {
                  "fixed": "c4c1e5d6bc2b900b2328d6fff93dc8146b858d69"
                },
                {
                  "fixed": "8e1bdf57de91247e57816482966265ada573cc74"
                },
                {
                  "fixed": "e382a4efeeae6555b95d9ff336cf3094ee7d336b"
                },
                {
                  "fixed": "4626df3f63c9185efba5750fe76ac01ab3351bae"
                },
                {
                  "fixed": "e51becb8f3377a377171ed5bf0082b96e22e6292"
                },
                {
                  "fixed": "6f1ef8170d3d8ad9319aa01347945dcdf5cc4f27"
                },
                {
                  "fixed": "451c9075d6c53f2438d110addbeeeea6fac18567"
                }
              ]
            }
          ],
          "database_specific": {
            "source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-74523.json"
          }
        },
        {
          "ranges": [
            {
              "type": "ECOSYSTEM",
              "events": [
                {
                  "introduced": "5.9.0"
                },
                {
                  "fixed": "5.10.265"
                }
              ]
            },
            {
              "type": "ECOSYSTEM",
              "events": [
                {
                  "introduced": "5.11.0"
                },
                {
                  "fixed": "5.15.216"
                }
              ]
            },
            {
              "type": "ECOSYSTEM",
              "events": [
                {
                  "introduced": "5.16.0"
                },
                {
                  "fixed": "6.1.183"
                }
              ]
            },
            {
              "type": "ECOSYSTEM",
              "events": [
                {
                  "introduced": "6.2.0"
                },
                {
                  "fixed": "6.6.151"
                }
              ]
            },
            {
              "type": "ECOSYSTEM",
              "events": [
                {
                  "introduced": "6.7.0"
                },
                {
                  "fixed": "6.12.103"
                }
              ]
            },
            {
              "type": "ECOSYSTEM",
              "events": [
                {
                  "introduced": "6.13.0"
                },
                {
                  "fixed": "6.18.44"
                }
              ]
            },
            {
              "type": "ECOSYSTEM",
              "events": [
                {
                  "introduced": "6.19.0"
                },
                {
                  "fixed": "7.1.8"
                }
              ]
            }
          ],
          "package": {
            "name": "Kernel",
            "ecosystem": "Linux"
          },
          "database_specific": {
            "source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-74523.json"
          }
        }
      ],
      "modified": "2026-10-28T02:30:42.229299290Z",
      "provider": "osv",
      "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",
        "https://git.kernel.org/stable/c/c4c1e5d6bc2b900b2328d6fff93dc8146b858d69",
        "https://git.kernel.org/stable/c/e382a4efeeae6555b95d9ff336cf3094ee7d336b",
        "https://git.kernel.org/stable/c/e51becb8f3377a377171ed5bf0082b96e22e6292",
        "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/74xxx/CVE-2026-74523.json",
        "https://nvd.nist.gov/vuln/detail/CVE-2026-74523",
        "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git"
      ],
      "provider_metadata": {
        "cna_assigner": "Linux",
        "osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/74xxx/CVE-2026-74523.json"
      }
    },
    "related_cves": [
      {
        "value": "CVE-2026-74523",
        "evidence": "/id"
      }
    ],
    "security_relevant": true,
    "severity_evidence": "/severity/0/score"
  },
  "source_id": "core-osv",
  "document_id": 510103,
  "published_at": "2026-08-15T12:27:40.575+00:00"
}