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

RDMA/rxe: Fix race condition in QP timer handlers

I encontered the following warning:
WARNING: drivers/infiniband/sw/rxe/rxe_task.c:249 at rxe_sched_task+0x1c8/0x238 [rdma_rxe], CPU#0: swapper/0/0
...
libsha1 [last unloaded: ip6_udp_tunnel]
CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Tainted: G C 6.19.0-rc5-64k-v8+ #37 PREEMPT
Tainted: [C]=CRAP
Hardware name: Raspberry Pi 4 Model B Rev 1.2
Call trace:
rxe_sched_task+0x1c8/0x238 [rdma_rxe] (P)
retransmit_timer+0x130/0x188 [rdma_rxe]
call_timer_fn+0x68/0x4d0
__run_timers+0x630/0x888
...
WARNING: drivers/infiniband/sw/rxe/rxe_task.c:38 at rxe_sched_task+0x1c0/0x238 [rdma_rxe], CPU#0: swapper/0/0
...
WARNING: drivers/infiniband/sw/rxe/rxe_task.c:111 at do_work+0x488/0x5c8 [rdma_rxe], CPU#3: kworker/u17:4/93400
...
refcount_t: underflow; use-after-free.
WARNING: lib/refcount.c:28 at refcount_warn_saturate+0x138/0x1a0, CPU#3: kworker/u17:4/93400

The issue is caused by a race condition between retransmit_timer() and
rxe_destroy_qp, leading to the Queue Pair's (QP) reference count dropping
to zero during timer handler execution.

It seems this warning is harmless because rxe_qp_do_cleanup() will flush
all pending timers and requests.

Example of flow causing the issue:

CPU0 CPU1
retransmit_timer() {
spin_lock_irqsave
rxe_destroy_qp()
__rxe_cleanup()
__rxe_put() // qp->ref_count decrease to 0
rxe_qp_do_cleanup() {
if (qp->valid) {
rxe_sched_task() {
WARN_ON(rxe_read(task->qp) <= 0);
}
}
spin_unlock_irqrestore
}
spin_lock_irqsave
qp->valid = 0
spin_unlock_irqrestore
}

Ensure the QP's reference count is maintained and its validity is checked
within the timer callbacks by adding calls to rxe_get(qp) and corresponding
rxe_put(qp) after use.
Published: 2026-05-27
Score: 7.8 High
EPSS: < 1% Very Low
KEV: No
Impact: n/a
Action: n/a
AI Analysis

Impact

A race between retransmit_timer() and rxe_destroy_qp() in the RDMA rxe driver can cause the reference count of a Queue Pair to drop to zero while a timer callback is still executing, triggering a refcount underflow. The kernel developers describe the resulting warning as harmless because the cleanup path flushes pending timers and requests before the queue pair is fully torn down. Still, the trigger for a use‑after‑free indicates a potential for kernel corruption or panic if the race can be timed precisely. The vulnerability is scored at CVSS 7.8, reflecting a high severity based on the theoretical impact of a kernel‑level use‑after‑free.

Affected Systems

All Linux kernels that include the rxe driver are potentially affected. No explicit version list is provided, so any installation of the Linux kernel that loads the rxe module—such as development releases or ARM‑based devices like the Raspberry Pi 4—may be impacted.

Risk and Exploitability

The EPSS score of less than 1% suggests a very low but non‑zero probability of exploitation. The flaw is not listed in CISA KEV. Attackers who can influence RDMA traffic or otherwise trigger the race may be able to cause a kernel crash or memory corruption; however, the kernel’s cleanup logic reduces the practical risk. The likely attack vector is through RDMA traffic, but this is inferred from the description because the vector is not explicitly stated.

Generated by OpenCVE AI on May 30, 2026 at 12:23 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Apply the kernel patch that incorporates the rxe race‑condition fix (commit 3c2ae79).
  • If a kernel upgrade cannot be performed immediately, unload or disable the rxe module to prevent RDMA traffic from triggering the race condition.
  • Alternatively, manually apply the upstream patch by building the updated rxe module from the specified commit and installing it into the running kernel.

Generated by OpenCVE AI on May 30, 2026 at 12:23 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Sat, 30 May 2026 11:00:00 +0000

Type Values Removed Values Added
Metrics cvssV3_1

{'score': 7.0, 'vector': 'CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H'}

cvssV3_1

{'score': 7.8, 'vector': 'CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H'}


Thu, 28 May 2026 12:15:00 +0000

Type Values Removed Values Added
Weaknesses CWE-911
References
Metrics threat_severity

None

cvssV3_1

{'score': 7.0, 'vector': 'CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H'}

threat_severity

Moderate


Wed, 27 May 2026 14:15:00 +0000

Type Values Removed Values Added
Description In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix race condition in QP timer handlers I encontered the following warning: WARNING: drivers/infiniband/sw/rxe/rxe_task.c:249 at rxe_sched_task+0x1c8/0x238 [rdma_rxe], CPU#0: swapper/0/0 ... libsha1 [last unloaded: ip6_udp_tunnel] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Tainted: G C 6.19.0-rc5-64k-v8+ #37 PREEMPT Tainted: [C]=CRAP Hardware name: Raspberry Pi 4 Model B Rev 1.2 Call trace: rxe_sched_task+0x1c8/0x238 [rdma_rxe] (P) retransmit_timer+0x130/0x188 [rdma_rxe] call_timer_fn+0x68/0x4d0 __run_timers+0x630/0x888 ... WARNING: drivers/infiniband/sw/rxe/rxe_task.c:38 at rxe_sched_task+0x1c0/0x238 [rdma_rxe], CPU#0: swapper/0/0 ... WARNING: drivers/infiniband/sw/rxe/rxe_task.c:111 at do_work+0x488/0x5c8 [rdma_rxe], CPU#3: kworker/u17:4/93400 ... refcount_t: underflow; use-after-free. WARNING: lib/refcount.c:28 at refcount_warn_saturate+0x138/0x1a0, CPU#3: kworker/u17:4/93400 The issue is caused by a race condition between retransmit_timer() and rxe_destroy_qp, leading to the Queue Pair's (QP) reference count dropping to zero during timer handler execution. It seems this warning is harmless because rxe_qp_do_cleanup() will flush all pending timers and requests. Example of flow causing the issue: CPU0 CPU1 retransmit_timer() { spin_lock_irqsave rxe_destroy_qp() __rxe_cleanup() __rxe_put() // qp->ref_count decrease to 0 rxe_qp_do_cleanup() { if (qp->valid) { rxe_sched_task() { WARN_ON(rxe_read(task->qp) <= 0); } } spin_unlock_irqrestore } spin_lock_irqsave qp->valid = 0 spin_unlock_irqrestore } Ensure the QP's reference count is maintained and its validity is checked within the timer callbacks by adding calls to rxe_get(qp) and corresponding rxe_put(qp) after use.
Title RDMA/rxe: Fix race condition in QP timer handlers
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-05-30T10:45:53.742Z

Reserved: 2026-05-13T15:03:33.084Z

Link: CVE-2026-45910

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Awaiting Analysis

Published: 2026-05-27T14:17:05.563

Modified: 2026-06-17T10:52:42.810

Link: CVE-2026-45910

cve-icon Redhat

Severity : Moderate

Publid Date: 2026-05-27T00:00:00Z

Links: CVE-2026-45910 - Bugzilla

cve-icon OpenCVE Enrichment

Updated: 2026-05-30T12:30:23Z

Weaknesses
  • CWE-911

    Improper Update of Reference Count