Copyright © 2012 Red Hat, Inc. All rights reserved. Moderate 2026-05-27T00:00:00 kernel: net/mlx5e: Fix deadlocks between devlink and netdev instance locks 5.5 CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H CWE-833

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

A flaw was found in the Linux kernel's mlx5e network driver. Incorrect lock ordering between devlink and netdev instance locks can lead to deadlocks. This issue can be triggered during various work tasks related to devlink health reporter recovery or concurrent channel tear down. A local attacker or specific network conditions could potentially exploit this to cause a Denial of Service (DoS) by making the system unresponsive.

Red Hat Enterprise Linux 10 Fix deferred kernel Red Hat Enterprise Linux 6 Out of support scope kernel Red Hat Enterprise Linux 7 Not affected kernel Red Hat Enterprise Linux 7 Not affected kernel-rt Red Hat Enterprise Linux 8 Not affected kernel Red Hat Enterprise Linux 8 Not affected kernel-rt Red Hat Enterprise Linux 9 Not affected kernel Red Hat Enterprise Linux 9 Not affected kernel-rt https://www.cve.org/CVERecord?id=CVE-2026-45907 https://nvd.nist.gov/vuln/detail/CVE-2026-45907 https://lore.kernel.org/linux-cve-announce/2026052721-CVE-2026-45907-2501@gregkh/T