How severe is CVE-2026-45907?

CVE-2026-45907 has a CVSS 3.x base score of 5.5, rated medium severity. It is exploitable over local access with low attack complexity, requires low privileges and no user interaction. Impact on confidentiality is none, integrity none, and availability high.

Is CVE-2026-45907 being actively exploited?

It is not currently listed in CISA's KEV catalog. Its EPSS exploit-prediction score is 0% (2nd percentile), an estimate of the probability of exploitation in the next 30 days.

What products are affected by CVE-2026-45907?

CVE-2026-45907 affects Linux Linux Kernel. See the affected-products list for the exact vulnerable versions.

How do I fix CVE-2026-45907?

Review the linked vendor and NVD advisories for patched versions and mitigations, then upgrade or apply the recommended workaround.

Does CVE-2026-45907 have an EU (EUVD) identifier?

Yes. CVE-2026-45907 is tracked in the ENISA EU Vulnerability Database (EUVD) as EUVD-2026-32373.

When was CVE-2026-45907 published?

CVE-2026-45907 was published on 2026-05-27 and last updated on 2026-06-24.

CVE-2026-45907

CVE-2026-45907 is a medium-severity vulnerability in Linux Linux Kernel with a CVSS 3.x base score of 5.5. It is not currently listed as actively exploited by CISA, and its EPSS exploit-prediction score is low. The underlying weakness is classified as CWE-667.

Key facts

Severity: Medium (CVSS 3.x base score 5.5)
EPSS exploit prediction: 0% (2nd percentile)
Actively exploited: Not listed in CISA KEV
EU (EUVD) id: EUVD-2026-32373
Weakness: CWE-667
Affected product: Linux Linux Kernel
Published: 2026-05-27
Last modified: 2026-06-24

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.

Frequently asked questions

What is CVE-2026-45907?: 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.
How severe is CVE-2026-45907?: CVE-2026-45907 has a CVSS 3.x base score of 5.5, rated medium severity. It is exploitable over local access with low attack complexity, requires low privileges and no user interaction. Impact on confidentiality is none, integrity none, and availability high.
Is CVE-2026-45907 being actively exploited?: It is not currently listed in CISA's KEV catalog. Its EPSS exploit-prediction score is 0% (2nd percentile), an estimate of the probability of exploitation in the next 30 days.
What products are affected by CVE-2026-45907?: CVE-2026-45907 affects Linux Linux Kernel. See the affected-products list for the exact vulnerable versions.
How do I fix CVE-2026-45907?: Review the linked vendor and NVD advisories for patched versions and mitigations, then upgrade or apply the recommended workaround.
Does CVE-2026-45907 have an EU (EUVD) identifier?: Yes. CVE-2026-45907 is tracked in the ENISA EU Vulnerability Database (EUVD) as EUVD-2026-32373.
When was CVE-2026-45907 published?: CVE-2026-45907 was published on 2026-05-27 and last updated on 2026-06-24.

References

Affected products (1)

cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*

More vulnerabilities in Linux Linux Kernel

CVE-2023-2163 — Critical (CVSS 10.0): Incorrect verifier pruning in BPF in Linux Kernel >=5.4 leads to unsafe code paths being incorrectly marked as safe,…
CVE-2015-8104 — Critical (CVSS 10.0): The KVM subsystem in the Linux kernel through 4.2.6, and Xen 4.3.x through 4.6.x, allows guest OS users to cause a…
CVE-2015-1421 — Critical (CVSS 10.0): Use-after-free vulnerability in the sctp_assoc_update function in net/sctp/associola.c in the Linux kernel before…
CVE-2014-2523 — Critical (CVSS 10.0): net/netfilter/nf_conntrack_proto_dccp.c in the Linux kernel through 3.13.6 uses a DCCP header pointer incorrectly,…
CVE-2010-2495 — Critical (CVSS 10.0): The pppol2tp_xmit function in drivers/net/pppol2tp.c in the L2TP implementation in the Linux kernel before 2.6.34 does…
CVE-2010-2521 — Critical (CVSS 10.0): Multiple buffer overflows in fs/nfsd/nfs4xdr.c in the XDR implementation in the NFS server in the Linux kernel before…

All CVEs affecting Linux Linux Kernel →

Other CWE-667 (Improper Locking) vulnerabilities

CVE-2020-12658 — Critical (CVSS 9.8): gssproxy (aka gss-proxy) before 0.8.3 does not unlock cond_mutex before pthread exit in gp_worker_main() in…
CVE-2019-5886 — Critical (CVSS 9.8): An issue was discovered in ShopXO 1.2.0. In the application\install\controller\Index.php file, there is no validation…
CVE-2026-43215 — High (CVSS 8.8): In the Linux kernel, the following vulnerability has been resolved: cifs: Fix locking usage for tcon fields We used…
CVE-2026-31629 — High (CVSS 8.8): In the Linux kernel, the following vulnerability has been resolved: nfc: llcp: add missing return after LLCP_CLOSED…
CVE-2020-15674 — High (CVSS 8.8): Mozilla developers reported memory safety bugs present in Firefox 80. Some of these bugs showed evidence of memory…
CVE-2021-1622 — High (CVSS 8.6): A vulnerability in the Common Open Policy Service (COPS) of Cisco IOS XE Software for Cisco cBR-8 Converged Broadband…

Browse all CWE-667 (Improper Locking) vulnerabilities →