CVE-2026-43468 in Linux
Summary
by MITRE • 05/08/2026
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5: Fix deadlock between devlink lock and esw->wq
esw->work_queue executes esw_functions_changed_event_handler -> esw_vfs_changed_event_handler and acquires the devlink lock.
.eswitch_mode_set (acquires devlink lock in devlink_nl_pre_doit) -> mlx5_devlink_eswitch_mode_set -> mlx5_eswitch_disable_locked -> mlx5_eswitch_event_handler_unregister -> flush_workqueue deadlocks when esw_vfs_changed_event_handler executes.
Fix that by no longer flushing the work to avoid the deadlock, and using a generation counter to keep track of work relevance. This avoids an old handler manipulating an esw that has undergone one or more mode changes: - the counter is incremented in mlx5_eswitch_event_handler_unregister. - the counter is read and passed to the ephemeral mlx5_host_work struct. - the work handler takes the devlink lock and bails out if the current generation is different than the one it was scheduled to operate on. - mlx5_eswitch_cleanup does the final draining before destroying the wq.
No longer flushing the workqueue has the side effect of maybe no longer cancelling pending vport_change_handler work items, but that's ok since those are disabled elsewhere: - mlx5_eswitch_disable_locked disables the vport eq notifier. - mlx5_esw_vport_disable disarms the HW EQ notification and marks vport->enabled under state_lock to false to prevent pending vport handler from doing anything. - mlx5_eswitch_cleanup destroys the workqueue and makes sure all events are disabled/finished.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 05/22/2026
The vulnerability resides in the Mellanox ConnectX-5 and newer network interface controllers within the Linux kernel's mlx5 driver, specifically within the extended switch (esw) component that manages virtual function (VF) configuration and device link management. This issue manifests as a deadlock condition that occurs during the transition between different switch modes, creating a critical operational disruption for network virtualization environments.
The technical flaw originates from a circular dependency between two critical synchronization mechanisms within the driver's locking architecture. The eswitch work queue executes a sequence of handlers including esw_functions_changed_event_handler and esw_vfs_changed_event_handler, which acquire the devlink lock as part of their execution flow. When the eswitch mode is being changed, the mlx5_eswitch_disable_locked function attempts to unregister event handlers and flush the workqueue, but this operation encounters a deadlock scenario. The deadlock occurs because the esw_vfs_changed_event_handler is still executing while the flushing process attempts to acquire the same devlink lock that the handler already holds, creating a classic circular wait condition that prevents system progression.
The operational impact of this vulnerability extends beyond simple system hangs, affecting the reliability of network virtualization deployments where live migration and runtime configuration changes are common. Network administrators may experience complete service disruption when attempting to modify switch modes, particularly in environments using SR-IOV virtualization where multiple VFs are managed dynamically. The vulnerability affects systems using Mellanox ConnectX-5 and newer hardware that implement the mlx5 driver with extended switch functionality, potentially impacting data center networks, cloud infrastructure, and high-performance computing clusters that rely on these network interfaces.
The fix implements a generation counter mechanism to avoid the deadlock scenario while maintaining functional integrity. Instead of flushing the workqueue which causes the circular dependency, the solution uses a generation counter that increments each time event handlers are unregistered. This counter is passed to ephemeral work structures and checked by handler functions before execution, allowing them to gracefully skip operations if the eswitch state has changed since the work was scheduled. The cleanup process ensures proper draining of work items before destroying the workqueue, while other mechanisms handle cancellation of pending vport change notifications through explicit disabling of event notifiers and hardware EQ notifications. This approach aligns with the principles of lock-free programming patterns and addresses the fundamental issue identified in CWE-362 (Concurrent Execution using Shared Resource with Unprotected Read-Write Access) and follows ATT&CK technique T1490 (Inhibit System Recovery) by preventing the system from becoming unresponsive during critical operations.
The mitigation strategy maintains backward compatibility while eliminating the race condition that led to the deadlock. The generation counter implementation provides a lightweight mechanism to ensure that stale work items do not interfere with current system states, though it does introduce a potential side effect where some pending vport_change_handler work items might not be cancelled immediately. However, this side effect is considered acceptable because the system ensures proper cleanup through the explicit disabling of notifiers and the final workqueue destruction process, maintaining overall system stability and preventing any functional degradation in normal operating conditions.