CVE-2026-45973: Linux Kernel Race Condition Vulnerability

CVE-2026-45973 Overview

CVE-2026-45973 is a Linux kernel vulnerability in the RDMA/mlx5 driver. A race condition occurs during firmware reset in Link Aggregation (LAG) mode, causing the driver to hang indefinitely while waiting for User Mode Memory Registration (UMR) completion during device unload. In LAG mode, the bond device is registered only on the master, so it never receives sys_error events from the slave. When the slave dies during firmware reset, the master has not yet entered error state, so UMR posts succeed but completions never arrive.

Critical Impact
The flaw causes indefinite driver hangs during device unload on Mellanox ConnectX adapters configured in LAG mode, disrupting RDMA-dependent workloads.

Affected Products

Linux kernel RDMA/mlx5 driver
Mellanox ConnectX network adapters operating in LAG mode
Systems using mlx5_core and mlx5_ib kernel modules

Discovery Timeline

2026-05-27 - CVE-2026-45973 published to NVD
2026-05-27 - Last updated in NVD database

Technical Details for CVE-2026-45973

Vulnerability Analysis

The vulnerability is a race condition [CWE-362] in the mlx5_ib InfiniBand driver during firmware reset handling in LAG configurations. When firmware reset occurs, the driver issues UMR work requests as part of teardown. Memory region deregistration via __mlx5_ib_dereg_mr() blocks on a mutex while waiting for completions that the dead slave device can no longer generate.

The call trace shows the hang originating in mlx5_sync_reset_reload_work(), propagating through mlx5_unload_one(), mlx5_lag_disable_change(), and ultimately stalling inside ib_dereg_mr_user(). Worker threads block indefinitely in __mutex_lock, freezing teardown operations.

Root Cause

In LAG mode, the bond device registration occurs only on the master physical function. The slave function never delivers sys_error notifications to the bond device. During firmware reset, the slave enters an error state while the master remains operational. UMR work requests submitted to the device succeed at post time but produce no completions, since the underlying hardware path is broken on the slave side.

Attack Vector

This vulnerability is triggered by firmware reset events on mlx5 devices configured in LAG mode rather than by remote attacker input. The condition manifests as a denial-of-service through driver hang during device unload. The upstream fix introduces a sys_error notifier registered before MLX5_IB_STAGE_IB_REG that remains active until after ib_unregister_device() completes, ensuring error events reach the bond device throughout teardown.

No synthetic exploitation code is provided. Refer to the upstream commits for technical patch details: Kernel Git Commit 613f5d4, Kernel Git Commit 6d83887, Kernel Git Commit c8fb5c9, and Kernel Git Commit ebc2164.

Detection Methods for CVE-2026-45973

Indicators of Compromise

Kernel worker threads blocked in __mlx5_ib_dereg_mr with __mutex_lock in D (uninterruptible sleep) state.
mlx5_sync_reset_reload_work appearing in hung task warnings from the kernel log.
RDMA applications stalling during firmware reset events on LAG-bonded mlx5 interfaces.

Detection Strategies

Monitor dmesg and /var/log/messages for hung_task_timeout_secs warnings referencing mlx5_ib symbols.
Inspect kernel stack traces of processes in D state via cat /proc/<pid>/stack to identify the blocked UMR path.
Track firmware reset events via mlx5 driver health logs and correlate with subsequent unload failures.

Monitoring Recommendations

Audit kernel versions on hosts running Mellanox ConnectX adapters in LAG mode and compare against patched stable releases.
Enable kernel hung_task detection (/proc/sys/kernel/hung_task_timeout_secs) to surface stalled teardown operations.
Forward kernel telemetry to a central log platform for correlation across RDMA-heavy fleets such as HPC, AI training, and storage clusters.

How to Mitigate CVE-2026-45973

Immediate Actions Required

Update affected systems to a Linux kernel release containing the upstream RDMA/mlx5 fix referenced in the four stable commits.
Inventory hosts running mlx5_core and mlx5_ib with bonded interfaces and prioritize patching for RDMA-dependent workloads.
Schedule firmware reset operations during maintenance windows until patched kernels are deployed.

Patch Information

The fix adds a sys_error notifier registered before MLX5_IB_STAGE_IB_REG that persists until after ib_unregister_device(). This ensures the bond device receives error events from slave functions throughout teardown, preventing UMR waits from hanging. Patches are available in the upstream stable trees via commits 613f5d4, 6d83887, c8fb5c9, and ebc2164.

Workarounds

Avoid LAG mode on mlx5 devices in environments where firmware reset events are frequent, until kernels are patched.
Manually quiesce RDMA workloads before any planned firmware reset operation.
Use watchdogs to detect stalled mlx5 teardown and force reboot affected nodes to restore service.

bash

# Verify running kernel and mlx5 driver version
uname -r
modinfo mlx5_core | grep -E '^(version|srcversion)'
modinfo mlx5_ib   | grep -E '^(version|srcversion)'

# Check for hung mlx5 teardown threads
dmesg -T | grep -Ei 'mlx5|hung_task|__mlx5_ib_dereg_mr'

# Inspect blocked task stacks
for p in $(ps -eo pid,stat,comm | awk '$2 ~ /D/ {print $1}'); do
  echo "PID $p:"; cat /proc/$p/stack 2>/dev/null
done