CVE-2026-45907

Analyzed Analyzed - Analysis Complete

Deadlock in Linux Kernel MLX5e Driver

Publication date: 2026-05-27

Last updated on: 2026-06-24

Assigner: kernel.org

Description

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.

CVSS Scores

EPSS Scores

Probability:
Percentile:

Meta Information

Published

2026-05-27

Last Modified

2026-06-24

Generated

2026-07-07

AI Q&A

2026-05-27

EPSS Evaluated

2026-07-05

NVD

CVE-2026-45907

EUVD

EUVD-2026-32373

Affected Vendors & Products

Vendor	Product	Version / Range
linux	linux_kernel	From 6.19 (inc) to 6.19.4 (exc)
linux	linux_kernel	From 6.16 (inc) to 6.18.14 (exc)

Helpful Resources

Exploitability

CWE

KEV

CWE ID	Description
CWE-667	The product does not properly acquire or release a lock on a resource, leading to unexpected resource state changes and behaviors.

Attack-Flow Graph

Executive Summary

This vulnerability is a deadlock issue in the Linux kernel related to the mlx5e network driver. It occurs due to incorrect ordering of locks between devlink and netdev instances during recovery work tasks triggered by the devlink health reporter.

Specifically, the recovery flow acquires locks in the wrong order (netdev lock before devlink lock), which conflicts with the correct lock order established during initialization (devlink lock before netdev lock). This incorrect lock ordering can cause deadlocks.

The fix involved moving netdev_trylock calls lower in the call stack within the recovery functions to ensure locks are acquired in the proper order, preventing deadlocks.

Impact Analysis

This vulnerability can cause deadlocks in the Linux kernel's network driver, which may lead to system hangs or degraded network performance.

Deadlocks can prevent proper recovery of network channels, potentially causing network outages or instability on affected systems.

Mitigation Strategies

The vulnerability involves deadlocks in the Linux kernel's mlx5e network driver due to incorrect lock ordering between devlink and netdev instance locks.

To mitigate this vulnerability, you should update your Linux kernel to a version that includes the fix described, which corrects the lock ordering by moving netdev_trylock calls to the appropriate recovery functions.

Hi! I’m here to help you understand CVE-2026-45907. Ask me anything about the vulnerability, its impact, or mitigation strategies.

0/70