CVE-2026-45907

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5e: Fix deadlocks between devlink and netdev instance locks<br /> <br /> In the mentioned "Fixes" commit, various work tasks triggering devlink<br /> health reporter recovery were switched to use netdev_trylock to protect<br /> against concurrent tear down of the channels being recovered. But this<br /> had the side effect of introducing potential deadlocks because of<br /> incorrect lock ordering.<br /> <br /> The correct lock order is described by the init flow:<br /> probe_one -&gt; mlx5_init_one (acquires devlink lock)<br /> -&gt; mlx5_init_one_devl_locked -&gt; mlx5_register_device<br /> -&gt; mlx5_rescan_drivers_locked -...-&gt; mlx5e_probe -&gt; _mlx5e_probe<br /> -&gt; register_netdev (acquires rtnl lock)<br /> -&gt; register_netdevice (acquires netdev lock)<br /> =&gt; devlink lock -&gt; rtnl lock -&gt; netdev lock.<br /> <br /> But in the current recovery flow, the order is wrong:<br /> mlx5e_tx_err_cqe_work (acquires netdev lock)<br /> -&gt; mlx5e_reporter_tx_err_cqe -&gt; mlx5e_health_report<br /> -&gt; devlink_health_report (acquires devlink lock =&gt; boom!)<br /> -&gt; devlink_health_reporter_recover<br /> -&gt; mlx5e_tx_reporter_recover -&gt; mlx5e_tx_reporter_recover_from_ctx<br /> -&gt; mlx5e_tx_reporter_err_cqe_recover<br /> <br /> The same pattern exists in:<br /> mlx5e_reporter_rx_timeout<br /> mlx5e_reporter_tx_ptpsq_unhealthy<br /> mlx5e_reporter_tx_timeout<br /> <br /> Fix these by moving the netdev_trylock calls from the work handlers<br /> lower in the call stack, in the respective recovery functions, where<br /> they are actually necessary.