{"cve":"CVE-2026-45907","nvd":{"published":"2026-05-27T14:17:05.233","modified":"2026-06-24T16:27:56.443","status":"Undergoing Analysis","description":"In the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: Fix deadlocks between devlink and netdev instance locks\n\nIn the mentioned \"Fixes\" commit, various work tasks triggering devlink\nhealth reporter recovery were switched to use netdev_trylock to protect\nagainst concurrent tear down of the channels being recovered. But this\nhad the side effect of introducing potential deadlocks because of\nincorrect lock ordering.\n\nThe correct lock order is described by the init flow:\nprobe_one -> mlx5_init_one (acquires devlink lock)\n-> mlx5_init_one_devl_locked -> mlx5_register_device\n-> mlx5_rescan_drivers_locked -...-> mlx5e_probe -> _mlx5e_probe\n-> register_netdev (acquires rtnl lock)\n-> register_netdevice (acquires netdev lock)\n=> devlink lock -> rtnl lock -> netdev lock.\n\nBut in the current recovery flow, the order is wrong:\nmlx5e_tx_err_cqe_work (acquires netdev lock)\n-> mlx5e_reporter_tx_err_cqe -> mlx5e_health_report\n-> devlink_health_report (acquires devlink lock => boom!)\n-> devlink_health_reporter_recover\n-> mlx5e_tx_reporter_recover -> mlx5e_tx_reporter_recover_from_ctx\n-> mlx5e_tx_reporter_err_cqe_recover\n\nThe same pattern exists in:\nmlx5e_reporter_rx_timeout\nmlx5e_reporter_tx_ptpsq_unhealthy\nmlx5e_reporter_tx_timeout\n\nFix these by moving the netdev_trylock calls from the work handlers\nlower in the call stack, in the respective recovery functions, where\nthey are actually necessary.","cvss_v4":null,"cvss_v3":{"version":"3.1","vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H","score":5.5},"cwes":["CWE-667"],"references":["https://git.kernel.org/stable/c/4329514c61abefe4961541b128c549b017bab5ad","https://git.kernel.org/stable/c/63f9d5fb4d8040077df801ca3270e2f02d55e0d9","https://git.kernel.org/stable/c/83ac0304a2d77519dae1e54c9713cbe1aedf19c9"],"products":["linux:linux_kernel"],"source":"nvd","synced_at":"2026-10-19T22:36:28.938604137+00:00"},"epss":{"cve":"CVE-2026-45907","score":0.00119,"percentile":0.01739,"date":"2026-10-31"},"kev":null,"osv":[],"attribution":["This product uses the NVD API but is not endorsed or certified by the NVD.","EPSS scores: FIRST Exploit Prediction Scoring System, https://www.first.org/epss","Known exploited vulnerabilities: CISA Known Exploited Vulnerabilities Catalog, https://www.cisa.gov/known-exploited-vulnerabilities-catalog","Package advisories: OSV (https://osv.dev), from the GitHub Advisory Database, PyPA, Go, RustSec and other ecosystem databases, under CC-BY 4.0 or CC0","CVE records: the CVE Program's CVE List (https://www.cve.org), under its terms of use (https://www.cve.org/Legal/TermsOfUse). CVE is a registered trademark of The MITRE Corporation; this product is not affiliated with the CVE Program."]}