Skip to content
CVE Ledger
  • Newest CVEsPage
  • Recently added to KEVPage
  • Rising exploitation (EPSS)Page
  • Weekly digestPage
  • StatisticsPage
  • WatchlistPage
  • API docsPage
  • MCP serverPage
  • AboutPage
  • Data sourcesPage
  • Data statusPage
  • ChangelogPage
  • How it's builtPage
  • Support the projectPage

14 results

Back

CVE-2026-45907net/mlx5e: Fix deadlocks between devlink and netdev instance locks

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.

Timeline

  1. ID reserved

    By Linux

  2. · 14 days later

    Published

Changes after publication (a new score, a public exploit, EPSS crossing 1, 10 or 50 %, leaving KEV) are kept since November 2026; earlier ones are not known.

Scores

CVSS scores of CVE-2026-45907, by who scored it
Scored byCVSSScoreVector
NVDNVD · Undergoing Analysis3.1Medium5.5CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
EPSS (exploitation in 30 days)
0.12% · top 98% of all CVEs (12 Nov 2026)
Loading the EPSS history…

The list uses the assigner's score when there is one, then CISA's, then NVD's: Medium 5.5.

Affected products

  • Linux · Linux

    • affected 8f7b00307bf14676b7e7f0210110a36aa0ff3e93 – < 4329514c61abefe4961541b128c549b017bab5ad
    • affected 8f7b00307bf14676b7e7f0210110a36aa0ff3e93 – < 63f9d5fb4d8040077df801ca3270e2f02d55e0d9
    • affected 8f7b00307bf14676b7e7f0210110a36aa0ff3e93 – < 83ac0304a2d77519dae1e54c9713cbe1aedf19c9
  • Linux · Linux

    • affected 6.16
    • unaffected < 6.16
    • unaffected 6.18.14 – ≤ 6.18.*
    • unaffected 6.19.4 – ≤ 6.19.*
    • unaffected 7.0 – ≤ *

References

References3

Sources

The same CVE in the primary databases and aggregators, to check against.

Badge for a README or a ticket

CVE-2026-45907 badge
[![CVE-2026-45907](https://cveledger.app/badge/CVE-2026-45907.svg)](https://cveledger.app/cve/CVE-2026-45907)

Record last updated .