CVE-2026-45910

What it actually does

This is a race condition in the Linux kernel Soft-RoCE RDMA driver (`rdma_rxe`) involving Queue Pair timer callbacks and Queue Pair destruction. A retransmission timer can continue operating while `rxe_destroy_qp()` is tearing down the same Queue Pair, allowing the Queue Pair reference count to drop to zero while timer-handler code still references it. The observed failure mode is a kernel warning and `refcount_t` underflow consistent with a use-after-free condition. In worst-case scenarios, a local attacker with the ability to interact with RDMA/RXE interfaces could attempt to turn the race into kernel memory corruption, potentially affecting confidentiality, integrity, and availability at kernel privilege level.

Why it matters to the business

Systems using the Linux kernel RDMA RXE/Soft-RoCE functionality may be exposed to local kernel instability or potential privilege escalation. The most immediate operational risk is host crashes, service interruption, or degraded reliability on workloads that use RDMA emulation. Because exploitation requires local access and the EPSS score is currently very low, this is less urgent than remotely exploitable kernel issues, but it should still be prioritized on multi-user systems, container hosts, HPC environments, virtualization platforms, and servers where untrusted users or workloads can access RDMA devices.

How an attack unfolds

An attacker first needs local code execution on a Linux system where the `rdma_rxe` module is present and usable. They then create or manipulate RXE RDMA Queue Pairs and drive activity that causes retransmission timers to fire while concurrently triggering Queue Pair teardown. By repeatedly racing `retransmit_timer()` against `rxe_destroy_qp()`, the attacker attempts to reach the vulnerable timing window where the Queue Pair reference count reaches zero while a timer callback still uses the object. Successful triggering may produce kernel warnings, reference-count underflow messages, denial of service, or, if the memory corruption is controllable on a given kernel/build configuration, potential kernel privilege escalation.

How to fix it

Apply a Linux kernel update from the operating system or kernel vendor that includes the RDMA/RXE fix adding proper Queue Pair reference handling and validity checks in timer callbacks. No exact fixed package versions were provided in the input, so use the vendor advisory or stable kernel changelog for the affected distribution. If immediate patching is not possible and RXE/Soft-RoCE is not required, unload and prevent loading of the `rdma_rxe` module, and restrict access to RDMA device nodes such as `/dev/infiniband/*`. On systems that require RDMA, limit local user access to RDMA-capable devices, avoid granting unnecessary container/device passthrough access, and ensure kernel hardening options and crash recovery monitoring are enabled.

How to confirm the fix worked

Confirm that the running kernel includes the upstream or vendor backport for the RDMA/RXE Queue Pair timer race fix. Validate exposure by checking whether `rdma_rxe` is loaded with `lsmod`, whether RXE links are configured with RDMA tooling, and whether `/dev/infiniband` device nodes are accessible to untrusted users or workloads. After remediation, verify that the updated kernel is running after reboot, not merely installed. Review `dmesg`, kernel journal logs, and crash dumps for absence of recurring `rdma_rxe`, `rxe_sched_task`, `retransmit_timer`, and `refcount_t: underflow; use-after-free` warnings under normal RDMA workload testing.

Typical attack path

1. Gain local execution on a Linux system, such as through a shell, compromised service account, container escape prerequisite, or malicious local workload.
2. Determine whether RDMA RXE/Soft-RoCE support is loaded or available, for example via the `rdma_rxe` kernel module and `/dev/infiniband` interfaces.
3. Create and exercise RDMA RXE Queue Pairs to generate retransmission timer activity.
4. Concurrently destroy or tear down Queue Pairs while timer callbacks are active to trigger the race condition.
5. Repeat the race until the kernel emits warnings, crashes, or reaches a usable memory-corruption state.
6. Leverage the resulting kernel memory corruption for denial of service or attempted local privilege escalation, depending on exploit reliability and platform protections.

How to detect it

Look for evidence that the race condition has already been triggered in kernel logs, system journals, crash dumps, and monitoring telemetry. Relevant sources include `dmesg`, `journalctl -k`, `/var/log/kern.log`, `/var/log/messages`, `/var/log/syslog`, kdump/vmcore analysis, and EDR telemetry that captures kernel warnings or module activity. Search for repeated warnings involving `rdma_rxe`, `rxe_sched_task`, `retransmit_timer`, `rxe_destroy_qp`, `rxe_qp_do_cleanup`, and `refcount_t` underflow. Correlate such events with local user sessions, container workloads, RDMA test tools, unexpected creation/destruction of RDMA resources, host crashes, or panics. Because no public exploit maturity or known KEV exploitation is indicated, detection should focus on anomalous local triggering patterns and kernel reliability events rather than fixed malware indicators.

• rdma_rxe
• rxe_sched_task
• retransmit_timer
• rxe_destroy_qp
• rxe_qp_do_cleanup
• refcount_t: underflow; use-after-free
• WARNING: drivers/infiniband/sw/rxe/rxe_task.c
• WARNING: lib/refcount.c
• rxe_sched_task+0x1c8
• rxe_sched_task+0x1c0
• do_work+0x488
• retransmit_timer+0x130
• /dev/infiniband
• drivers/infiniband/sw/rxe/rxe_task.c
• lib/refcount.c

What your security team should do

• Patch affected Linux kernels through the relevant OS or kernel vendor update channel, prioritizing systems where RDMA RXE is enabled or accessible to untrusted local users.
• Inventory hosts with the `rdma_rxe` module loaded or available, RXE interfaces configured, or `/dev/infiniband` exposed to users, containers, or virtualized workloads.
• If RXE/Soft-RoCE is not required, unload `rdma_rxe` and block it from autoloading using module blacklist or equivalent kernel module policy.
• Restrict permissions on RDMA device nodes and remove unnecessary users from RDMA-capable groups or device access policies.
• Review kernel logs and crash telemetry for signs of prior triggering, especially repeated `rdma_rxe` warnings, `refcount_t` underflow messages, or unexplained host panics.
• For container platforms, audit device passthrough and privileged container configurations that could expose RDMA interfaces to untrusted workloads.
• Track vendor advisories for exact fixed kernel package versions and confirm reboot completion after kernel updates.