net/mlx5: Fix deadlock between devlink lock and esw->wq

Summary

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.

Timeline

1. May 8, 2026, 2:22 PM UTCCVE published
2. May 11, 2026, 10:25 PM UTCRecord last updated

Affected versions

• Linux Linux

  Version range not reported

• Linux Linux

  6.0

References 6