CVE-2026-45973

What it actually does

This is a Linux kernel race condition in the mlx5 RDMA driver when Mellanox/NVIDIA mlx5 devices are operating in LAG/bonding mode. During a firmware reset or device unload, the bond device may not receive the relevant sys_error event from the slave device. As a result, UMR operations can be posted successfully but never complete, causing teardown paths such as memory-region deregistration and RDMA device unregister to wait indefinitely. The practical technical effect is a kernel-level hang in mlx5_ib/mlx5_core teardown paths, leading to denial of service or stuck driver/device recovery. The vulnerability does not provide confidentiality or integrity impact based on the published description.

Why it matters to the business

Systems using mlx5 RDMA-capable adapters in LAG mode can become unstable or hang during firmware reset, device unload, driver reload, or related recovery operations. In environments that rely on RDMA for storage, HPC, virtualization, AI/ML clusters, or high-throughput networking, this can cause workload interruption, node evacuation, failed maintenance, degraded cluster capacity, or require a forced reboot. The issue is not listed in CISA KEV, is not known to be used in ransomware campaigns, and has a very low EPSS score, so broad exploitation likelihood appears low; however, affected high-availability or performance-sensitive systems may experience significant operational impact if the triggering conditions occur.

How an attack unfolds

An attacker needs local access to an affected Linux system and the ability to interact with RDMA resources or influence device reset/unload conditions on a host using mlx5 hardware in LAG mode. The attacker can create or hold RDMA user resources, then trigger or wait for a firmware reset, driver unload, LAG disablement, or device teardown sequence. Because the bond device may miss the slave device error notification, the driver proceeds as though UMR requests can complete, but completions never arrive. Kernel teardown code then blocks while deregistering memory regions or unregistering the RDMA device. The result is a persistent hang in the mlx5 RDMA driver path, potentially requiring administrative intervention or reboot to restore service. No public exploit maturity is indicated, and exploitation is constrained to hosts with the specific mlx5 RDMA/LAG configuration.

How to fix it

Apply a Linux kernel update that includes the RDMA/mlx5 fix adding a sys_error notifier that remains registered through RDMA device teardown. Because no exact fixed package versions were provided, use the fixed kernel versions supplied by the relevant Linux distribution, kernel vendor, appliance vendor, or cloud image provider. Prioritize systems with Mellanox/NVIDIA mlx5 adapters, RDMA enabled, and LAG/bonding configured. If immediate patching is not possible, reduce exposure by avoiding unnecessary driver unload/reload operations, firmware resets, and LAG mode changes during production workloads; schedule such operations during maintenance windows; drain RDMA workloads before firmware or driver maintenance; and consider disabling RDMA or LAG on nonessential systems where operationally feasible.

How to confirm the fix worked

Confirm that the running kernel package contains the vendor fix for the mlx5 RDMA LAG sys_error notifier race. Validate exposure by checking whether the system uses mlx5_core/mlx5_ib modules, RDMA devices, and LAG/bonding mode. After patching, test controlled firmware reset, driver reload, device unload, or LAG disable/enable operations in a non-production or drained environment and confirm that mlx5_ib unload and ib_unregister_device complete without hangs. Review kernel logs before and after remediation for mlx5 firmware reset events, RDMA teardown call traces, blocked tasks, or hung worker threads involving mlx5_ib, mlx5_core, ib_core, or ib_uverbs.

Typical attack path

1. Identify a Linux host with mlx5 RDMA-capable hardware using LAG/bonding mode.
2. Obtain local access with sufficient privileges or capabilities to use RDMA interfaces or influence device/driver lifecycle events.
3. Open RDMA user resources, such as memory regions or uverbs file descriptors, that will be cleaned up during device teardown.
4. Trigger or coincide with a firmware reset, mlx5 driver reload, LAG disablement, eswitch disablement, or device unload.
5. Cause the mlx5_ib teardown path to wait indefinitely for UMR completion that will never arrive.
6. Degrade availability by leaving the RDMA device, kernel worker, or host maintenance operation hung until recovery or reboot.

How to detect it

To determine whether this issue was already triggered, review kernel logs from dmesg, journald, syslog, and any centralized logging platform for mlx5 firmware reset, LAG disable, driver unload, RDMA device unregister, blocked task, or kernel call trace events. Focus on periods around firmware maintenance, NIC reset, bonding/LAG changes, driver reloads, PCI rescans, or unexplained node hangs. Look for stack traces containing mlx5_ib, mlx5_core, ib_core, ib_uverbs, UMR completion waits, memory-region deregistration, and ib_unregister_device. Also check for administrative commands or automation that performed modprobe/rmmod, devlink reload, firmware reset, system maintenance, or network bond reconfiguration shortly before the hang. Because this vulnerability causes an availability failure rather than a clean malware-style artifact, detection is based mainly on kernel telemetry, stuck tasks, and operational timelines rather than network IOCs.

• __mlx5_ib_dereg_mr
• ib_dereg_mr_user
• uverbs_destroy_uobject
• __uverbs_cleanup_ufile
• ib_uverbs_remove_one
• __ib_unregister_device
• ib_unregister_device
• __mlx5_ib_remove
• mlx5_rescan_drivers_locked
• mlx5_disable_lag
• mlx5_lag_disable_change
• mlx5_eswitch_disable
• mlx5_unload
• mlx5_unload_one
• mlx5_sync_reset_reload_work
• wait_for_completion
• schedule_preempt_disabled
• mlx5_ib
• mlx5_core
• ib_core
• ib_uverbs
• UMR
• LAG error state
• firmware reset
• blocked for more than
• Call Trace:

What your security team should do

• Inventory Linux systems with mlx5_core or mlx5_ib loaded, Mellanox/NVIDIA ConnectX-class adapters, RDMA enabled, and LAG/bonding configured.
• Prioritize kernel updates on RDMA-dependent infrastructure such as storage, virtualization, HPC, AI/ML, and low-latency networking clusters.
• Coordinate patching with operations teams because remediation may require kernel upgrade and reboot.
• Until patched, avoid nonessential firmware resets, driver reloads, PCI rescans, LAG reconfiguration, and mlx5 unload operations on production nodes.
• Add monitoring for kernel hung-task reports and call traces involving mlx5_ib, mlx5_core, UMR, ib_unregister_device, and ib_uverbs_remove_one.
• If suspected exploitation or accidental triggering occurs, preserve dmesg, journalctl kernel logs, RDMA configuration, loaded module list, and recent administrative command history before rebooting when feasible.
• Treat this primarily as an availability risk rather than a data theft or privilege escalation issue unless additional local compromise indicators are present.