CVE-2026-45907 Overview
CVE-2026-45907 is a deadlock vulnerability in the Linux kernel's net/mlx5e Mellanox Ethernet driver. The flaw stems from incorrect lock ordering between the devlink lock, RTNL lock, and netdev instance lock during devlink health reporter recovery operations. A prior fix introduced netdev_trylock calls in work handlers to protect against concurrent channel teardown, but this inverted the established lock acquisition order. The upstream kernel maintainers resolved the issue by moving the netdev_trylock calls lower in the call stack into the respective recovery functions where they are actually required.
Critical Impact
Concurrent execution of devlink health reporter recovery and netdev teardown can cause kernel deadlock, leading to denial of service on systems using Mellanox ConnectX adapters.
Affected Products
- Linux kernel net/mlx5e driver for Mellanox ConnectX network adapters
- Kernel branches referenced in commits 4329514, 63f9d5f, and 83ac030
- Systems using devlink health reporter recovery for mlx5e channels
Discovery Timeline
- 2026-05-27 - CVE-2026-45907 published to NVD
- 2026-05-27 - Last updated in NVD database
Technical Details for CVE-2026-45907
Vulnerability Analysis
The vulnerability is a lock-ordering deadlock [Deadlock] in the Linux kernel net/mlx5e driver. The kernel's initialization flow establishes a strict lock hierarchy: devlink lock is acquired first, followed by the RTNL lock, then the netdev instance lock. This ordering is set during probe_one -> mlx5_init_one -> mlx5_register_device -> mlx5e_probe -> register_netdev -> register_netdevice.
A prior commit modified devlink health reporter recovery work tasks to call netdev_trylock to guard against concurrent channel teardown. This change inadvertently inverted the lock order in the recovery path.
Root Cause
In the recovery flow, mlx5e_tx_err_cqe_work acquires the netdev lock first, then calls mlx5e_reporter_tx_err_cqe -> mlx5e_health_report -> devlink_health_report, which attempts to acquire the devlink lock. This produces the inverted sequence netdev lock -> devlink lock, violating the canonical devlink -> RTNL -> netdev ordering and creating a deadlock window with the initialization path.
The same pattern exists in mlx5e_reporter_rx_timeout, mlx5e_reporter_tx_ptpsq_unhealthy, and mlx5e_reporter_tx_timeout.
Attack Vector
This is a local, race-condition denial-of-service condition. Triggering the deadlock requires concurrent occurrence of a device error condition (such as a TX CQE error, RX timeout, or PTP unhealthy state) alongside an operation that exercises the standard lock acquisition path. The condition is environmental and not directly remotely exploitable, but it can be triggered by adverse network conditions affecting Mellanox hardware.
No proof-of-concept exploit code has been published. The vulnerability manifests as a kernel hang on affected systems. See the kernel commits referenced below for the precise code paths.
Detection Methods for CVE-2026-45907
Indicators of Compromise
- Kernel soft lockup or hung task warnings referencing mlx5e_tx_err_cqe_work, mlx5e_reporter_rx_timeout, mlx5e_reporter_tx_ptpsq_unhealthy, or mlx5e_reporter_tx_timeout in dmesg output
- Stuck tasks blocked on devlink_health_report or netdev_trylock in /proc/<pid>/stack
- Loss of network connectivity on interfaces backed by the mlx5_core driver without preceding link-down events
Detection Strategies
- Monitor kernel ring buffer for INFO: task ... blocked for more than messages involving mlx5e work queues
- Enable lockdep (CONFIG_PROVE_LOCKING) on test systems to surface the inverted devlink/netdev lock order at runtime
- Correlate devlink health reporter state transitions with netdev register or unregister events for anomalies
Monitoring Recommendations
- Track running kernel version against the patched commits 4329514c61ab, 63f9d5fb4d80, and 83ac0304a2d7 across the Linux fleet
- Alert on repeated mlx5_core health reporter recovery events, which indicate hardware error conditions that could trigger the deadlock
- Forward dmesg and journald kernel logs into a centralized logging or SIEM platform for cross-host correlation of mlx5e errors
How to Mitigate CVE-2026-45907
Immediate Actions Required
- Inventory all hosts running Mellanox ConnectX adapters with the mlx5_core and mlx5e drivers loaded
- Apply the upstream kernel patches that relocate netdev_trylock calls into the recovery functions
- Update to a stable Linux kernel release containing the fix once your distribution publishes it
Patch Information
The fix is delivered through three upstream kernel commits that restructure the lock acquisition path in mlx5e devlink health reporter recovery. The patches move netdev_trylock calls from the work handlers into the recovery functions where they are actually required, restoring the canonical devlink -> RTNL -> netdev lock ordering. Reference: Kernel Git Commit 4329514, Kernel Git Commit 63f9d5f, and Kernel Git Commit 83ac030.
Workarounds
- No supported workaround eliminates the deadlock without applying the upstream patch
- Reduce exposure by minimizing conditions that trigger mlx5e health reporter recovery, such as resolving upstream network errors and PTP synchronization issues
- Stage kernel updates through configuration management tooling to ensure consistent rollout across servers using Mellanox NICs
# Verify mlx5_core driver and kernel version on affected hosts
uname -r
modinfo mlx5_core | grep -E '^(version|srcversion|filename)'
dmesg | grep -E 'mlx5e_(tx_err_cqe_work|reporter_(rx_timeout|tx_ptpsq_unhealthy|tx_timeout))'
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
