Skip to main content

Linux Kernel CVE-2026-43468

| EUVDEUVD-2026-28774 MEDIUM
Improper Locking (CWE-667)
2026-05-08 Linux GHSA-7gc8-cffq-4r9r
5.5
CVSS 3.1 · NVD
Share

Severity by source

NVD PRIMARY
5.5 MEDIUM
AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
SUSE
MEDIUM
qualitative
Red Hat
5.5 MEDIUM
qualitative

Primary rating from NVD.

CVSS VectorNVD

CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Attack Vector
Local
Attack Complexity
Low
Privileges Required
Low
User Interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
None
Availability
High

Lifecycle Timeline

4
Analysis Generated
May 21, 2026 - 15:08 vuln.today
CVSS changed
May 21, 2026 - 15:07 NVD
5.5 (MEDIUM)
Patch available
May 08, 2026 - 16:18 EUVD
CVE Published
May 08, 2026 - 14:22 nvd
UNKNOWN (no severity yet)

DescriptionCVE.org

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.

AnalysisAI

Deadlock in the Linux kernel's mlx5 network driver eswitch subsystem allows a local low-privileged user to cause a complete system hang (denial of service) on hosts equipped with Mellanox/NVIDIA ConnectX NICs operating in SR-IOV eswitch mode. The deadlock arises from a lock-ordering inversion: the eswitch work queue acquires the devlink lock while processing VF change events, and concurrently the eswitch mode-set path holds the devlink lock and calls flush_workqueue, producing a circular wait. No public exploit code exists and no active exploitation has been identified at time of analysis; EPSS probability is 0.02%, reflecting the narrow, hardware-specific attack surface.

Technical ContextAI

The net/mlx5 subsystem is the Linux kernel driver for Mellanox (now NVIDIA) ConnectX series SmartNICs. The eswitch (embedded switch) component manages SR-IOV virtual functions (VFs) and their lifecycle events. CWE-667 (Improper Locking) describes the root cause: two execution contexts each hold a lock and attempt to acquire the other's lock, creating a classic AB-BA deadlock. Specifically, esw->work_queue processes VF change events via esw_vfs_changed_event_handler, which acquires the devlink lock. Separately, .eswitch_mode_set acquires the devlink lock in devlink_nl_pre_doit before calling mlx5_eswitch_disable_locked, which then calls mlx5_eswitch_event_handler_unregister, which calls flush_workqueue - at which point the work item is blocked waiting to acquire the devlink lock already held by the calling thread. The fix introduces a generation counter on the eswitch struct to detect stale work items without requiring a synchronous flush, eliminating the circular wait. Affected CPE: cpe:2.3:a:linux:linux:*:*:*:*:*:*:*:* from the commit introducing the vulnerable path (f1bc646c9a06f09aad5d8bacb87103b5573ee45e) through the respective stable-branch fix commits.

RemediationAI

The primary fix is to upgrade the Linux kernel to a patched stable release: 6.1.167 (or later in the 6.1.x series), 6.6.130 (or later in the 6.6.x series), 6.12.78 (or later in the 6.12.x series), 6.18.19 (or later in the 6.18.x series), or 6.19.9 (or later in the 6.19.x series). Upstream fix commits are referenced at https://git.kernel.org/stable/c/0de867f6e34eae6907b367fd152c55e61cb98608 and related links above. As a compensating control where patching is not immediately feasible, disabling SR-IOV eswitch mode on affected mlx5 devices eliminates the vulnerable code path entirely, though this will disable SR-IOV VF functionality and may impact workloads dependent on hardware-assisted network virtualization. Restricting local shell access to unprivileged users on affected hypervisor nodes reduces attack surface but does not eliminate the vulnerability, since PR:L suffices. No generic firewall or network-level control mitigates this local kernel deadlock.

Vendor StatusVendor

SUSE

Severity: Medium
Product Status
SUSE Linux Enterprise Desktop 15 SP7 Fixed
SUSE Linux Enterprise Desktop 15 SP7 Fixed
SUSE Linux Enterprise High Availability Extension 15 SP7 Fixed
SUSE Linux Enterprise High Availability Extension 15 SP7 Fixed
SUSE Linux Enterprise High Performance Computing 15 SP7 Fixed

Share

CVE-2026-43468 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy