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
Move the netdev_trylock calls from the mlx5e_tx_err_cqe_work, mlx5e_reporter_rx_timeout, mlx5e_reporter_tx_ptpsq_unhealthy, and mlx5e_reporter_tx_timeout work handlers lower in the call stack into their respective recovery functions, where they are necessary, to preserve the lock order devlink lock -> rtnl lock -> netdev lock.
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.