From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: linux-cve-announce@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@kernel.org>
Subject: CVE-2026-43468: net/mlx5: Fix deadlock between devlink lock and esw->wq
Date: Fri, 8 May 2026 16:23:17 +0200 [thread overview]
Message-ID: <2026050803-CVE-2026-43468-8a20@gregkh> (raw)
From: Greg Kroah-Hartman <gregkh@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.
The Linux kernel CVE team has assigned CVE-2026-43468 to this issue.
Affected and fixed versions
===========================
Issue introduced in 6.0 with commit f1bc646c9a06f09aad5d8bacb87103b5573ee45e and fixed in 6.1.167 with commit 0de867f6e34eae6907b367fd152c55e61cb98608
Issue introduced in 6.0 with commit f1bc646c9a06f09aad5d8bacb87103b5573ee45e and fixed in 6.6.130 with commit 957d2a58f7f8ebcbdd0a85935e0d2675134b890d
Issue introduced in 6.0 with commit f1bc646c9a06f09aad5d8bacb87103b5573ee45e and fixed in 6.12.78 with commit 3c7313cb41b1b427078440364d2f042c276a1c0b
Issue introduced in 6.0 with commit f1bc646c9a06f09aad5d8bacb87103b5573ee45e and fixed in 6.18.19 with commit 4a7838bebc38374f74baaf88bf2cf8d439a92923
Issue introduced in 6.0 with commit f1bc646c9a06f09aad5d8bacb87103b5573ee45e and fixed in 6.19.9 with commit 90e7e5d14d0bd25ffd019a3aa39d9f1c05fedbe1
Issue introduced in 6.0 with commit f1bc646c9a06f09aad5d8bacb87103b5573ee45e and fixed in 7.0 with commit aed763abf0e905b4b8d747d1ba9e172961572f57
Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.
Unaffected versions might change over time as fixes are backported to
older supported kernel versions. The official CVE entry at
https://cve.org/CVERecord/?id=CVE-2026-43468
will be updated if fixes are backported, please check that for the most
up to date information about this issue.
Affected files
==============
The file(s) affected by this issue are:
drivers/net/ethernet/mellanox/mlx5/core/eswitch.c
drivers/net/ethernet/mellanox/mlx5/core/eswitch.h
drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
Mitigation
==========
The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes. Individual
changes are never tested alone, but rather are part of a larger kernel
release. Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all. If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
https://git.kernel.org/stable/c/0de867f6e34eae6907b367fd152c55e61cb98608
https://git.kernel.org/stable/c/957d2a58f7f8ebcbdd0a85935e0d2675134b890d
https://git.kernel.org/stable/c/3c7313cb41b1b427078440364d2f042c276a1c0b
https://git.kernel.org/stable/c/4a7838bebc38374f74baaf88bf2cf8d439a92923
https://git.kernel.org/stable/c/90e7e5d14d0bd25ffd019a3aa39d9f1c05fedbe1
https://git.kernel.org/stable/c/aed763abf0e905b4b8d747d1ba9e172961572f57
reply other threads:[~2026-05-08 14:26 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2026050803-CVE-2026-43468-8a20@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=cve@kernel.org \
--cc=gregkh@kernel.org \
--cc=linux-cve-announce@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox