CVE-2026-43468
Analyzed Analyzed - Analysis Complete
Deadlock in Linux Kernel MLX5 Driver

Publication date: 2026-05-08

Last updated on: 2026-05-21

Assigner: kernel.org

Description
In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Fix deadlock between devlink lock and esw->wq esw->work_queue executes esw_functions_changed_event_handler -> esw_vfs_changed_event_handler and acquires the devlink lock. .eswitch_mode_set (acquires devlink lock in devlink_nl_pre_doit) -> mlx5_devlink_eswitch_mode_set -> mlx5_eswitch_disable_locked -> mlx5_eswitch_event_handler_unregister -> flush_workqueue deadlocks when esw_vfs_changed_event_handler executes. Fix that by no longer flushing the work to avoid the deadlock, and using a generation counter to keep track of work relevance. This avoids an old handler manipulating an esw that has undergone one or more mode changes: - the counter is incremented in mlx5_eswitch_event_handler_unregister. - the counter is read and passed to the ephemeral mlx5_host_work struct. - the work handler takes the devlink lock and bails out if the current generation is different than the one it was scheduled to operate on. - mlx5_eswitch_cleanup does the final draining before destroying the wq. No longer flushing the workqueue has the side effect of maybe no longer cancelling pending vport_change_handler work items, but that's ok since those are disabled elsewhere: - mlx5_eswitch_disable_locked disables the vport eq notifier. - mlx5_esw_vport_disable disarms the HW EQ notification and marks vport->enabled under state_lock to false to prevent pending vport handler from doing anything. - mlx5_eswitch_cleanup destroys the workqueue and makes sure all events are disabled/finished.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-05-08
Last Modified
2026-05-21
Generated
2026-06-19
AI Q&A
2026-05-08
EPSS Evaluated
2026-06-18
NVD
CVE-2026-43468
EUVD
EUVD-2026-28774
Affected Vendors & Products
Showing 8 associated CPEs
Vendor Product Version / Range
linux linux_kernel 7.0
linux linux_kernel 7.0
linux linux_kernel 7.0
linux linux_kernel From 6.2 (inc) to 6.6.130 (exc)
linux linux_kernel From 6.13 (inc) to 6.18.19 (exc)
linux linux_kernel From 6.7 (inc) to 6.12.78 (exc)
linux linux_kernel From 6.19 (inc) to 6.19.9 (exc)
linux linux_kernel From 6.0 (inc) to 6.1.167 (exc)
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-667 The product does not properly acquire or release a lock on a resource, leading to unexpected resource state changes and behaviors.
Attack-Flow Graph
AI Quick Actions
Instant insights powered by AI
Executive Summary

This vulnerability involves a deadlock in the Linux kernel's mlx5 network driver, specifically between the devlink lock and the eswitch work queue (wq). The deadlock occurs when the esw->work_queue executes certain event handlers that acquire the devlink lock, while at the same time, other functions that also acquire the devlink lock attempt to flush the workqueue, causing a deadlock situation.

The fix avoids flushing the workqueue to prevent the deadlock and introduces a generation counter to track the relevance of work items. This counter helps ensure that old handlers do not operate on an eswitch that has changed modes. The fix also includes disabling and cleaning up work items and notifications properly to maintain system stability.

Impact Analysis

This deadlock vulnerability can cause the affected Linux kernel system to hang or become unresponsive when the mlx5 network driver's eswitch work queue and devlink lock interact improperly. This can lead to degraded network performance or system instability, potentially impacting services relying on the network functionality provided by the mlx5 driver.

Mitigation Strategies

This vulnerability has been resolved by changes in the Linux kernel's mlx5 driver related to the handling of the devlink lock and eswitch workqueue to avoid deadlocks.

To mitigate this vulnerability immediately, you should update your Linux kernel to a version that includes the fix for this issue.

The fix involves avoiding flushing the workqueue to prevent deadlocks and using a generation counter to track work relevance, ensuring that old handlers do not manipulate eswitch states incorrectly.

Chat Assistant
Ask questions about this CVE
Hi! I’m here to help you understand CVE-2026-43468. Ask me anything about the vulnerability, its impact, or mitigation strategies.
0/70
EPSS Chart