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.
Published: 2026-05-27
Score: 5.5 Medium
EPSS: < 1% Very Low
KEV: No
Impact: n/a
Action: n/a
AI Analysis

Impact

The Linux kernel contains a bug in the mlx5e driver where incorrect lock ordering between the devlink and netdevice locks can cause a deadlock during recovery operations such as tx_err_cqe_work, reporter_rx_timeout, and other health reporter routines. The deadlock halts the kernel, resulting in a system freeze or crash but it does not expose data or provide code execution.

Affected Systems

The flaw affects any Linux kernel build that includes the mlx5e driver before the fix commit. Specific kernel versions are not listed, so all recent distributions shipping the buggy driver source code are potentially vulnerable until the patch is applied.

Risk and Exploitability

The CVSS score of 5.5 indicates moderate severity. The EPSS score is less than 1 % and the vulnerability is not in CISA’s KEV, suggesting a low likelihood of widespread exploitation. The likely attack vector involves local privileged or kernel-level execution that triggers driver recovery or health reporting; this inference is made because the deadlock occurs during kernel operations that are not exposed to remote users. The impact is mainly availability loss through a kernel crash, with no impact on confidentiality or integrity.

Generated by OpenCVE AI on May 28, 2026 at 17:17 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Apply a Linux kernel update that includes the commit 4329514c61abefe4961541b128c549b017bab5ad which restores correct lock ordering.
  • If a kernel update cannot be applied immediately, unload or disable the mlx5e driver or any network interfaces that use it to prevent the deadlock path from executing.
  • Test the updated kernel in a staging environment and monitor system stability before rolling the patch out to production.

Generated by OpenCVE AI on May 28, 2026 at 17:17 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Thu, 28 May 2026 15:15:00 +0000

Type Values Removed Values Added
Weaknesses CWE-667
CWE-767

Thu, 28 May 2026 12:15:00 +0000

Type Values Removed Values Added
Weaknesses CWE-833
References
Metrics threat_severity

None

 cvssV3_1

{'score': 5.5, 'vector': 'CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H'}

threat_severity

Moderate

Wed, 27 May 2026 22:00:00 +0000

Type Values Removed Values Added
Weaknesses CWE-667
CWE-767

Wed, 27 May 2026 14:15:00 +0000

Type Values Removed Values Added
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.
Title net/mlx5e: Fix deadlocks between devlink and netdev instance locks
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-05-27T12:17:20.424Z

Reserved: 2026-05-13T15:03:33.084Z

Link: CVE-2026-45907

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Awaiting Analysis

Published: 2026-05-27T14:17:05.233

Modified: 2026-05-27T14:48:03.013

Link: CVE-2026-45907

cve-icon Redhat

Severity : Moderate

Publid Date: 2026-05-27T00:00:00Z

Links: CVE-2026-45907 - Bugzilla

cve-icon OpenCVE Enrichment

Updated: 2026-05-28T17:30:15Z

Weaknesses