CVE-2026-45907: net/mlx5e: Fix deadlocks between devlink and netdev instance locks
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 netdevtrylock 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: probeone -> mlx5initone (acquires devlink lock) -> mlx5initonedevllocked -> mlx5registerdevice -> mlx5rescandriverslocked -...-> mlx5eprobe -> mlx5eprobe -> registernetdev (acquires rtnl lock) -> registernetdevice (acquires netdev lock) => devlink lock -> rtnl lock -> netdev lock.
But in the current recovery flow, the order is wrong: mlx5etxerrcqework (acquires netdev lock) -> mlx5ereportertxerrcqe -> mlx5ehealthreport -> devlinkhealthreport (acquires devlink lock => boom!) -> devlinkhealthreporterrecover -> mlx5etxreporterrecover -> mlx5etxreporterrecoverfromctx -> mlx5etxreportererrcqerecover
The same pattern exists in: mlx5ereporterrxtimeout mlx5ereportertxptpsqunhealthy mlx5ereportertxtimeout
Fix these by moving the netdevtrylock calls from the work handlers lower in the call stack, in the respective recovery functions, where they are actually necessary.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
In the net/mlx5e code, move netdev_trylock invocations out of work-handler contexts and into the lower-level recovery call paths to preserve the correct lock ordering (devlink -> rtnl -> netdev). Concretely: remove netdev_trylock from work handlers such as mlx5e_tx_err_cqe_work, mlx5e_reporter_rx_timeout, mlx5e_reporter_tx_timeout, and mlx5e_reporter_tx_ptpsq_unhealthy, and instead acquire netdev protection in the respective recovery functions (for example: mlx5e_tx_reporter_recover, mlx5e_tx_reporter_recover_from_ctx, mlx5e_reporter_tx_err_cqe -> mlx5e_health_report, devlink_health_reporter_recover). Also ensure init/probe related paths (e.g. mlx5_init_one_devl_locked -> mlx5_register_device and mlx5_rescan_drivers_locked -> mlx5e_probe -> _mlx5e_probe) follow the same ordering to avoid devlink lock -> rtnl lock -> netdev lock deadlocks.
Event History
Frequently Asked Questions
What is the severity of CVE-2026-45907?
The severity of CVE-2026-45907 is medium with a CVSS score of 5.5.
What type of vulnerability is CVE-2026-45907?
CVE-2026-45907 is a vulnerability related to deadlocks between devlink and netdev instance locks in the Linux kernel.
How do I fix CVE-2026-45907?
To fix CVE-2026-45907, update the Linux kernel to the patched version that addresses the deadlock issue.
What are the potential impacts of CVE-2026-45907?
The potential impact of CVE-2026-45907 includes system instability and possible denial of service due to deadlocks.
Which software versions are affected by CVE-2026-45907?
CVE-2026-45907 affects certain versions of the Linux kernel, particularly those utilizing the mlx5e driver.