CVE-2026-43468: Linux Kernel Race Condition Vulnerability

CVE-2026-43468 Overview

CVE-2026-43468 is a deadlock vulnerability in the Linux kernel's Mellanox net/mlx5 Ethernet switch (eswitch) driver. The flaw occurs between the devlink lock and the eswitch work queue (esw->wq). When .eswitch_mode_set acquires the devlink lock through devlink_nl_pre_doit, the call chain reaches mlx5_eswitch_event_handler_unregister, which invokes flush_workqueue. If esw_vfs_changed_event_handler is concurrently executing and waiting for the same devlink lock, the two paths deadlock. This issue affects systems running affected Linux kernel versions with the mlx5 driver, commonly deployed on servers using NVIDIA/Mellanox ConnectX network adapters in SR-IOV configurations.

Critical Impact
Triggering the deadlock stalls kernel threads handling eswitch mode changes and VF function events, resulting in a denial-of-service condition on hosts using Mellanox mlx5 adapters.

Affected Products

Linux kernel net/mlx5 Ethernet driver
Systems using NVIDIA/Mellanox ConnectX network adapters with SR-IOV eswitch enabled
Distributions shipping the impacted kernel commits prior to the referenced fixes

Discovery Timeline

2026-05-08 - CVE-2026-43468 published to NVD
2026-05-12 - Last updated in NVD database

Technical Details for CVE-2026-43468

Vulnerability Analysis

The defect is a classic [CWE-833] deadlock in kernel synchronization between two lock-acquiring paths in the mlx5 eswitch subsystem. One path runs from the eswitch work queue: esw->work_queue executes esw_functions_changed_event_handler, which calls esw_vfs_changed_event_handler and attempts to acquire the devlink lock. The competing path originates from a netlink request through .eswitch_mode_set, which already holds the devlink lock via devlink_nl_pre_doit. That path descends into mlx5_devlink_eswitch_mode_set, mlx5_eswitch_disable_locked, and mlx5_eswitch_event_handler_unregister, then calls flush_workqueue to wait for pending work. Because the pending work itself is blocked waiting for the devlink lock, the system deadlocks.

Root Cause

The root cause is lock-order inversion. The kernel control path holds the devlink lock and then synchronously waits for queued work, while that work tries to acquire the devlink lock. The driver previously relied on flush_workqueue for ordering but did not coordinate the lock acquisition order between the two paths.

Attack Vector

Administrative or privileged operations that toggle the eswitch mode while function-change events are being processed can reach the vulnerable code path. Exploitation does not appear to enable code execution or privilege escalation; the observable impact is a kernel hang affecting networking functionality on the affected host. No public proof-of-concept or in-the-wild exploitation has been reported.

The upstream fix removes the flush_workqueue call and introduces a generation counter. The counter increments in mlx5_eswitch_event_handler_unregister, is captured by each scheduled mlx5_host_work instance, and is re-checked under the devlink lock so stale handlers exit without manipulating a reconfigured eswitch. Final draining occurs in mlx5_eswitch_cleanup before the workqueue is destroyed. See the patch commits referenced in Kernel Git Commit aed763a and Kernel Git Commit 957d2a5 for the full implementation.

Detection Methods for CVE-2026-43468

Indicators of Compromise

Kernel hung task warnings referencing flush_workqueue, mlx5_eswitch_disable_locked, or mlx5_eswitch_event_handler_unregister in dmesg.
Tasks stuck in D state holding or waiting on the devlink mutex while esw_vfs_changed_event_handler appears in stack traces.
Loss of network management responsiveness on hosts using mlx5_core with SR-IOV eswitch operations.

Detection Strategies

Parse kernel logs for INFO: task ... blocked for more than messages correlated with the mlx5_core module and devlink operations.
Use crash or /proc/<pid>/stack to inspect blocked kernel threads and confirm contention on the devlink lock and esw->wq.
Inventory hosts running affected kernel builds without the upstream commits listed in the references.

Monitoring Recommendations

Alert on repeated softlockup or hung-task reports involving the mlx5 driver and devlink subsystem.
Track kernel package versions across the fleet to confirm rollout of patched builds.
Monitor network management plane health, including failures of devlink dev eswitch set operations and SR-IOV VF reconfiguration.

How to Mitigate CVE-2026-43468

Immediate Actions Required

Identify systems running the mlx5_core driver with SR-IOV eswitch enabled and prioritize them for patching.
Apply the upstream kernel fixes referenced below and reboot to load the corrected mlx5_core module.
Avoid changing eswitch modes during active VF reconfiguration on unpatched hosts to reduce exposure to the deadlock window.

Patch Information

The fix is available in the mainline and stable Linux kernel trees through the following commits: Kernel Git Commit 0de867f, Kernel Git Commit 3c7313c, Kernel Git Commit 4a7838b, Kernel Git Commit 90e7e5d, Kernel Git Commit 957d2a5, and Kernel Git Commit aed763a. Consume the fix through your distribution's stable kernel update once available.

Workarounds

Limit privileged users authorized to invoke devlink dev eswitch set on production hosts until patches are deployed.
Schedule eswitch mode changes during maintenance windows when VF function-change events are not expected.
If a host enters the deadlocked state, recovery generally requires a reboot since the affected kernel threads cannot be unblocked safely.

bash

# Verify the running kernel and mlx5 driver version on affected hosts
uname -r
modinfo mlx5_core | grep -E '^(version|srcversion|filename):'

# Confirm whether eswitch mode operations are in use
devlink dev eswitch show