CVE-2026-43468

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5: Fix deadlock between devlink lock and esw-&gt;wq<br /> <br /> esw-&gt;work_queue executes esw_functions_changed_event_handler -&gt;<br /> esw_vfs_changed_event_handler and acquires the devlink lock.<br /> <br /> .eswitch_mode_set (acquires devlink lock in devlink_nl_pre_doit) -&gt;<br /> mlx5_devlink_eswitch_mode_set -&gt; mlx5_eswitch_disable_locked -&gt;<br /> mlx5_eswitch_event_handler_unregister -&gt; flush_workqueue deadlocks<br /> when esw_vfs_changed_event_handler executes.<br /> <br /> Fix that by no longer flushing the work to avoid the deadlock, and using<br /> a generation counter to keep track of work relevance. This avoids an old<br /> handler manipulating an esw that has undergone one or more mode changes:<br /> - the counter is incremented in mlx5_eswitch_event_handler_unregister.<br /> - the counter is read and passed to the ephemeral mlx5_host_work struct.<br /> - the work handler takes the devlink lock and bails out if the current<br /> generation is different than the one it was scheduled to operate on.<br /> - mlx5_eswitch_cleanup does the final draining before destroying the wq.<br /> <br /> No longer flushing the workqueue has the side effect of maybe no longer<br /> cancelling pending vport_change_handler work items, but that&amp;#39;s ok since<br /> those are disabled elsewhere:<br /> - mlx5_eswitch_disable_locked disables the vport eq notifier.<br /> - mlx5_esw_vport_disable disarms the HW EQ notification and marks<br /> vport-&gt;enabled under state_lock to false to prevent pending vport<br /> handler from doing anything.<br /> - mlx5_eswitch_cleanup destroys the workqueue and makes sure all events<br /> are disabled/finished.