{"api_version":"1","generated_at":"2026-05-29T22:34:21+00:00","cve":"CVE-2026-45907","urls":{"html":"https://cve.report/CVE-2026-45907","api":"https://cve.report/api/cve/CVE-2026-45907.json","docs":"https://cve.report/api","cve_org":"https://www.cve.org/CVERecord?id=CVE-2026-45907","nvd":"https://nvd.nist.gov/vuln/detail/CVE-2026-45907"},"summary":{"title":"net/mlx5e: Fix deadlocks between devlink and netdev instance locks","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.","state":"PUBLISHED","assigner":"Linux","published_at":"2026-05-27 14:17:05","updated_at":"2026-05-27 14:48:03"},"problem_types":[],"metrics":[],"references":[{"url":"https://git.kernel.org/stable/c/4329514c61abefe4961541b128c549b017bab5ad","name":"https://git.kernel.org/stable/c/4329514c61abefe4961541b128c549b017bab5ad","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/83ac0304a2d77519dae1e54c9713cbe1aedf19c9","name":"https://git.kernel.org/stable/c/83ac0304a2d77519dae1e54c9713cbe1aedf19c9","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/63f9d5fb4d8040077df801ca3270e2f02d55e0d9","name":"https://git.kernel.org/stable/c/63f9d5fb4d8040077df801ca3270e2f02d55e0d9","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-45907","name":"CVE Program record","refsource":"CVE.ORG","tags":["canonical"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-45907","name":"NVD vulnerability detail","refsource":"NVD","tags":["canonical","analysis"]}],"affected":[{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 8f7b00307bf14676b7e7f0210110a36aa0ff3e93 4329514c61abefe4961541b128c549b017bab5ad git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 8f7b00307bf14676b7e7f0210110a36aa0ff3e93 63f9d5fb4d8040077df801ca3270e2f02d55e0d9 git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 8f7b00307bf14676b7e7f0210110a36aa0ff3e93 83ac0304a2d77519dae1e54c9713cbe1aedf19c9 git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 6.16","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 6.16 semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 6.18.14 6.18.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 6.19.4 6.19.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 7.0 * original_commit_for_fix","platforms":[]}],"timeline":[],"solutions":[],"workarounds":[],"exploits":[],"credits":[],"nvd_cpes":[],"vendor_comments":[],"enrichments":{"kev":null,"epss":{"cve_year":"2026","cve_id":"45907","cve":"CVE-2026-45907","epss":"0.000170000","percentile":"0.043220000","score_date":"2026-05-28","updated_at":"2026-05-29 00:13:15"},"legacy_qids":[]},"source_records":{"cve_program":{"containers":{"cna":{"affected":[{"defaultStatus":"unaffected","product":"Linux","programFiles":["drivers/net/ethernet/mellanox/mlx5/core/en/ptp.c","drivers/net/ethernet/mellanox/mlx5/core/en/reporter_rx.c","drivers/net/ethernet/mellanox/mlx5/core/en/reporter_tx.c","drivers/net/ethernet/mellanox/mlx5/core/en_main.c"],"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","versions":[{"lessThan":"4329514c61abefe4961541b128c549b017bab5ad","status":"affected","version":"8f7b00307bf14676b7e7f0210110a36aa0ff3e93","versionType":"git"},{"lessThan":"63f9d5fb4d8040077df801ca3270e2f02d55e0d9","status":"affected","version":"8f7b00307bf14676b7e7f0210110a36aa0ff3e93","versionType":"git"},{"lessThan":"83ac0304a2d77519dae1e54c9713cbe1aedf19c9","status":"affected","version":"8f7b00307bf14676b7e7f0210110a36aa0ff3e93","versionType":"git"}]},{"defaultStatus":"affected","product":"Linux","programFiles":["drivers/net/ethernet/mellanox/mlx5/core/en/ptp.c","drivers/net/ethernet/mellanox/mlx5/core/en/reporter_rx.c","drivers/net/ethernet/mellanox/mlx5/core/en/reporter_tx.c","drivers/net/ethernet/mellanox/mlx5/core/en_main.c"],"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","versions":[{"status":"affected","version":"6.16"},{"lessThan":"6.16","status":"unaffected","version":"0","versionType":"semver"},{"lessThanOrEqual":"6.18.*","status":"unaffected","version":"6.18.14","versionType":"semver"},{"lessThanOrEqual":"6.19.*","status":"unaffected","version":"6.19.4","versionType":"semver"},{"lessThanOrEqual":"*","status":"unaffected","version":"7.0","versionType":"original_commit_for_fix"}]}],"cpeApplicability":[{"nodes":[{"cpeMatch":[{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"6.18.14","versionStartIncluding":"6.16","vulnerable":true},{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"6.19.4","versionStartIncluding":"6.16","vulnerable":true},{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"7.0","versionStartIncluding":"6.16","vulnerable":true}],"negate":false,"operator":"OR"}]}],"descriptions":[{"lang":"en","value":"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."}],"providerMetadata":{"dateUpdated":"2026-05-27T12:17:20.424Z","orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux"},"references":[{"url":"https://git.kernel.org/stable/c/4329514c61abefe4961541b128c549b017bab5ad"},{"url":"https://git.kernel.org/stable/c/63f9d5fb4d8040077df801ca3270e2f02d55e0d9"},{"url":"https://git.kernel.org/stable/c/83ac0304a2d77519dae1e54c9713cbe1aedf19c9"}],"title":"net/mlx5e: Fix deadlocks between devlink and netdev instance locks","x_generator":{"engine":"bippy-1.2.0"}}},"cveMetadata":{"assignerOrgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","assignerShortName":"Linux","cveId":"CVE-2026-45907","datePublished":"2026-05-27T12:17:20.424Z","dateReserved":"2026-05-13T15:03:33.084Z","dateUpdated":"2026-05-27T12:17:20.424Z","state":"PUBLISHED"},"dataType":"CVE_RECORD","dataVersion":"5.2"},"nvd":{"publishedDate":"2026-05-27 14:17:05","lastModifiedDate":"2026-05-27 14:48:03","problem_types":[],"metrics":[],"configurations":[]},"legacy_mitre":{"record":{"CveYear":"2026","CveId":"45907","Ordinal":"1","Title":"net/mlx5e: Fix deadlocks between devlink and netdev instance loc","CVE":"CVE-2026-45907","Year":"2026"},"notes":[{"CveYear":"2026","CveId":"45907","Ordinal":"1","NoteData":"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.","Type":"Description","Title":"net/mlx5e: Fix deadlocks between devlink and netdev instance loc"}]}}}