CVE-2026-43468

What it actually does

This is a local denial-of-service flaw in the Linux kernel mlx5 network driver, affecting systems using Mellanox/NVIDIA ConnectX mlx5 devices with eswitch/devlink functionality such as SR-IOV or switchdev mode. A lock-ordering problem can deadlock the devlink lock and the mlx5 eswitch workqueue when eswitch mode changes occur while VF/eswitch change events are being processed. The result can be a stuck kernel workqueue, blocked devlink operations, impaired network device management, and potentially loss of networking availability on the affected host. The vulnerability requires local privileges sufficient to trigger relevant devlink/eswitch operations, so it is primarily a host-level availability risk rather than a remote code execution or data exposure issue.

Why it matters to the business

Successful exploitation can make network interfaces or network virtualization functions on affected Linux systems hang or become unavailable, disrupting workloads that depend on mlx5-based high-performance networking, SR-IOV, virtual functions, or switchdev configurations. The highest operational risk is on virtualization hosts, container platforms, NFV systems, storage fabrics, HPC clusters, and other environments where mlx5 adapters provide critical network connectivity. This issue is not currently listed in CISA KEV, has no known ransomware association, and has very low EPSS, so broad internet exploitation is unlikely; however, systems exposing local administrative or delegated network-management capabilities should still be patched during normal kernel maintenance windows.

How an attack unfolds

An attacker first needs local access with privileges that allow interaction with devlink or network device configuration. They then trigger or race mlx5 eswitch mode transitions with VF or eswitch change events, for example by changing eswitch mode while virtual function state changes are being processed. In vulnerable kernels, one execution path holds the devlink lock and attempts to flush the eswitch workqueue, while a queued eswitch handler attempts to acquire the same devlink lock. Because each side waits on the other, the kernel can deadlock that management path. The practical effect is denial of service: devlink operations may hang, mlx5 eswitch reconfiguration may stop progressing, and affected network functionality may require driver reset or host reboot to recover.

How to fix it

Upgrade to a Linux kernel version that includes the upstream mlx5 deadlock fix for the devlink/eswitch workqueue interaction. No exact fixed package versions were provided in the input, so use distribution-specific security advisories and kernel changelogs to identify the first fixed kernel for each supported platform. Prioritize systems with Mellanox/NVIDIA ConnectX mlx5 adapters using SR-IOV, switchdev, devlink eswitch mode changes, or frequent VF lifecycle operations. If immediate patching is not possible, reduce exposure by limiting local access to users and services that can run privileged network-management operations, restricting use of devlink/ip link controls through sudo/RBAC policies, avoiding unnecessary eswitch mode transitions, disabling unused SR-IOV/VF functionality where operationally feasible, and scheduling configuration changes during controlled maintenance windows. Reboot into the fixed kernel after installation; simply installing kernel packages without booting them does not remediate a running kernel flaw.

How to confirm the fix worked

Confirm remediation by verifying that systems are running a patched kernel from the relevant Linux distribution or vendor, not merely that an update package is installed. Inventory hosts for mlx5 usage with commands such as lspci, ethtool -i, lsmod, and devlink device listings, then compare the running kernel build against vendor advisories containing the fix. Validate that mlx5 interfaces remain manageable after eswitch mode changes and VF lifecycle operations in a controlled test environment. Review kernel logs after testing for hung task warnings, lockdep reports, workqueue stalls, or mlx5/devlink stack traces. For mitigations, confirm that only authorized administrators can execute devlink and privileged network configuration commands and that unnecessary SR-IOV/VF exposure has been disabled.

Typical attack path

1. Obtain local shell or workload-level access on a Linux system with mlx5 hardware and sufficient privileges to manage network devices, devlink, SR-IOV, or eswitch mode.
2. Identify mlx5 devices and whether eswitch/SR-IOV/switchdev functionality is enabled.
3. Trigger repeated or carefully timed eswitch mode changes while VF or eswitch events are occurring.
4. Cause the vulnerable lock interaction between devlink-held eswitch mode changes and the eswitch workqueue handler.
5. Induce a deadlock that blocks mlx5/devlink management operations and can degrade or disrupt network availability.
6. Maintain the denial-of-service condition until the driver, device, or host is reset or rebooted.

How to detect it

Look for evidence of attempted or successful denial of service rather than data theft. Relevant sources include kernel ring buffer logs, system journal entries, hypervisor or node management logs, command audit logs, sudo logs, shell history where available, and EDR telemetry for privileged network-management commands. Focus on systems with mlx5_core loaded or mlx5 PCI devices present. Signs of exploitation or accidental triggering include devlink commands that never return, eswitch mode changes hanging, VF provisioning or teardown failures, kernel hung-task messages, lockdep warnings, blocked workqueue threads, and stack traces containing mlx5 eswitch or devlink functions. Correlate these symptoms with local execution of devlink, ip link SR-IOV operations, driver reset actions, or automation that changes eswitch mode. Because this is a deadlock vulnerability, there may be no network IOC; the strongest evidence is temporal correlation between privileged local network configuration activity and kernel-level hangs involving mlx5/devlink code paths.

• mlx5_core
• mlx5_devlink_eswitch_mode_set
• mlx5_eswitch_disable_locked
• mlx5_eswitch_event_handler_unregister
• esw_functions_changed_event_handler
• esw_vfs_changed_event_handler
• devlink_nl_pre_doit
• flush_workqueue
• devlink dev eswitch set
• mode switchdev
• mode legacy
• blocked for more than
• INFO: task
• hung_task
• workqueue
• mlx5_eswitch_cleanup
• mlx5_esw_vport_disable
• sriov_numvfs

What your security team should do

• Inventory Linux systems using mlx5_core or Mellanox/NVIDIA ConnectX adapters, especially virtualization, Kubernetes, NFV, storage, and HPC hosts.
• Prioritize patching systems that use SR-IOV, switchdev, devlink eswitch mode transitions, or dynamic VF provisioning.
• Apply distribution-supported kernel updates containing the mlx5 eswitch/devlink deadlock fix and reboot into the fixed kernel.
• Restrict local privileged network-management capabilities, including devlink and eswitch mode changes, to trusted administrators and automation only.
• Monitor kernel logs for hung tasks, mlx5_core stack traces, devlink operation hangs, and workqueue deadlock symptoms until all affected systems are patched.
• Avoid repeated or automated eswitch mode changes on unpatched systems unless operationally necessary.
• Document recovery procedures for affected hosts, including interface reset, driver reload where safe, node drain, or reboot, because exploitation may require disruptive recovery.