Skip to main content

Linux Kernel CVE-2026-45973

| EUVDEUVD-2026-32257 MEDIUM
2026-05-27 416baaa9-dc9f-4396-8d5f-8c081fb06d67 GHSA-3hq7-v6j3-hpcm
Linux Information Disclosure Red Hat Suse
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
vuln.today AI
5.5 MEDIUM

Local kernel driver triggered only via LAG config and firmware reset; low-privilege local access sufficient; no confidentiality or integrity impact, only high-severity availability hang.

3.1 AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
4.0 AV:L/AC:L/AT:P/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
SUSE
4.7 MEDIUM
AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
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

5
Analysis Generated
Jun 16, 2026 - 02:54 vuln.today
CVSS changed
Jun 16, 2026 - 02:52 NVD
5.5 (MEDIUM)
Patch available
May 27, 2026 - 19:46 EUVD
CVE Published
May 27, 2026 - 14:17 nvd
MEDIUM 5.5
CVE Published
May 27, 2026 - 14:17 nvd
UNKNOWN (no severity yet)

DescriptionNVD

In the Linux kernel, the following vulnerability has been resolved:

RDMA/mlx5: Fix UMR hang in LAG error state unload

During firmware reset in LAG mode, a race condition causes the driver to hang indefinitely while waiting for UMR completion during device unload. See [1].

In LAG mode the bond device is only registered on the master, so it never sees sys_error events from the slave. During firmware reset this causes UMR waits to hang forever on unload as the slave is dead but the master hasn't entered error state yet, so UMR posts succeed but completions never arrive.

Fix this by adding a sys_error notifier that gets registered before MLX5_IB_STAGE_IB_REG and stays alive until after ib_unregister_device(). This ensures error events reach the bond device throughout teardown.

[1] Call Trace: __schedule+0x2bd/0x760 schedule+0x37/0xa0 schedule_preempt_disabled+0xa/0x10 __mutex_lock.isra.6+0x2b5/0x4a0 __mlx5_ib_dereg_mr+0x606/0x870 [mlx5_ib] ? __xa_erase+0x4a/0xa0 ? _cond_resched+0x15/0x30 ? wait_for_completion+0x31/0x100 ib_dereg_mr_user+0x48/0xc0 [ib_core] ? rdmacg_uncharge_hierarchy+0xa0/0x100 destroy_hw_idr_uobject+0x20/0x50 [ib_uverbs] uverbs_destroy_uobject+0x37/0x150 [ib_uverbs] __uverbs_cleanup_ufile+0xda/0x140 [ib_uverbs] uverbs_destroy_ufile_hw+0x3a/0xf0 [ib_uverbs] ib_uverbs_remove_one+0xc3/0x140 [ib_uverbs] remove_client_context+0x8b/0xd0 [ib_core] disable_device+0x8c/0x130 [ib_core] __ib_unregister_device+0x10d/0x180 [ib_core] ib_unregister_device+0x21/0x30 [ib_core] __mlx5_ib_remove+0x1e4/0x1f0 [mlx5_ib] auxiliary_bus_remove+0x1e/0x30 device_release_driver_internal+0x103/0x1f0 bus_remove_device+0xf7/0x170 device_del+0x181/0x410 mlx5_rescan_drivers_locked.part.10+0xa9/0x1d0 [mlx5_core] mlx5_disable_lag+0x253/0x260 [mlx5_core] mlx5_lag_disable_change+0x89/0xc0 [mlx5_core] mlx5_eswitch_disable+0x67/0xa0 [mlx5_core] mlx5_unload+0x15/0xd0 [mlx5_core] mlx5_unload_one+0x71/0xc0 [mlx5_core] mlx5_sync_reset_reload_work+0x83/0x100 [mlx5_core] process_one_work+0x1a7/0x360 worker_thread+0x30/0x390 ? create_worker+0x1a0/0x1a0 kthread+0x116/0x130 ? kthread_flush_work_fn+0x10/0x10 ret_from_fork+0x22/0x40

AnalysisAI

Indefinite kernel hang in the Linux mlx5_ib RDMA driver causes denial of service during device unload when a firmware reset occurs in LAG (Link Aggregation Group) mode. The race condition leaves UMR (User Memory Registration) deregistration operations blocked forever - posted on the master NIC but awaiting completions from a slave that is already dead - deadlocking the teardown sequence and requiring a hard reboot. No public exploit has been identified, EPSS sits at 0.02% (5th percentile), and impact is confined to systems with Mellanox/NVIDIA mlx5 hardware explicitly configured in bonded LAG mode with active RDMA workloads.

Technical ContextAI

The vulnerability is in the RDMA/mlx5 kernel driver (cpe:2.3:o:linux:linux_kernel), which supports Mellanox/NVIDIA ConnectX-series adapters. In LAG mode, two or more physical NICs are bonded, but the bond device is registered only on the master interface, not the slave. UMR (User Memory Registration) is the mechanism by which the kernel registers user-space memory for zero-copy RDMA operations; deregistration calls into __mlx5_ib_dereg_mr(), which must wait for a hardware completion event. During a firmware reset, the slave NIC is marked dead before the master enters error state, meaning UMR posts succeed on the master but completions are never delivered - they would originate from the now-dead slave. Because no sys_error notifier was wired to the bond device for the full MLX5_IB_STAGE_IB_REG-through-ib_unregister_device() window, error state never propagates to abort the wait, causing __mutex_lock to spin indefinitely. No formal CWE is assigned by NVD, but the root cause is a race condition in error-state propagation across bonded devices during teardown.

RemediationAI

Upgrade to a patched Linux kernel: 6.12.75 or later for the 6.12 stable branch, 6.18.14 for the 6.18 branch, 6.19.4 for the 6.19 branch, or 7.0 and later. The upstream fixes are available at https://git.kernel.org/stable/c/613f5d4139b6ba801ccd93f9a28943be60d903bc, https://git.kernel.org/stable/c/6d838873da9cb97551d42316967cc82bf8f8031b, https://git.kernel.org/stable/c/c8fb5c965ac7d0104872a8e4f6451f3bc6328199, and https://git.kernel.org/stable/c/ebc2164a4cd4314503f1a0c8e7aaf76d7e5fa211. If immediate patching is not feasible, a compensating control on mlx5 LAG deployments is to ensure all RDMA user-space applications are terminated and all memory regions deregistered before any firmware reset is initiated - this eliminates in-flight UMR operations that would deadlock. Alternatively, temporarily disabling LAG/bonding on the mlx5 interfaces prevents the race from manifesting, though this eliminates NIC redundancy. Disabling automatic firmware health recovery (mlx5 health polling) removes the self-healing trigger but also eliminates automatic error recovery capability - weigh this trade-off carefully in high-availability environments.

Same technique Information Disclosure

View all
CVE-2013-2251 CRITICAL POC
9.8
CVE-2017-5638 CRITICAL POC
9.8
CVE-2025-24813 CRITICAL POC
9.8
CVE-2015-1701 HIGH POC
7.8
CVE-2017-0147 HIGH POC
7.5
CVE-2014-6324 HIGH POC
8.8
CVE-2023-7028 CRITICAL POC
10.0
CVE-2017-0213 HIGH POC
7.3

Vendor StatusVendor

SUSE

Severity: Moderate
Product Status
SUSE Linux Enterprise Desktop 15 SP7 Affected
SUSE Linux Enterprise Desktop 15 SP7 Affected
SUSE Linux Enterprise High Availability Extension 15 SP7 Affected
SUSE Linux Enterprise High Availability Extension 15 SP7 Affected
SUSE Linux Enterprise High Performance Computing 15 SP7 Affected

Share

CVE-2026-45973 vulnerability details – vuln.today
Back

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