CVE-2026-45910

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/rxetask.c:249 at rxeschedtask+0x1c8/0x238 [rdmarxe], CPU#0: swapper/0/0 ... libsha1 [last unloaded: ip6udptunnel] 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: rxeschedtask+0x1c8/0x238 [rdmarxe] (P) retransmittimer+0x130/0x188 [rdmarxe] calltimer_fn+0x68/0x4d0 _runtimers+0x630/0x888 ... WARNING: drivers/infiniband/sw/rxe/rxetask.c:38 at rxeschedtask+0x1c0/0x238 [rdmarxe], CPU#0: swapper/0/0 ... WARNING: drivers/infiniband/sw/rxe/rxetask.c:111 at dowork+0x488/0x5c8 [rdmarxe], CPU#3: kworker/u17:4/93400 ... refcountt: underflow; use-after-free. WARNING: lib/refcount.c:28 at refcountwarnsaturate+0x138/0x1a0, CPU#3: kworker/u17:4/93400

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

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

Example of flow causing the issue:

CPU0 CPU1 retransmittimer() { spinlockirqsave rxedestroy_qp() __rxe_cleanup() _rxeput() // qp->refcount decrease to 0 rxeqpdocleanup() { if (qp->valid) { rxeschedtask() { WARNON(rxeread(task->qp) <= 0); } } spinunlockirqrestore } spinlockirqsave qp->valid = 0 spinunlockirqrestore }

Ensure the QP's reference count is maintained and its validity is checked within the timer callbacks by adding calls to rxeget(qp) and corresponding rxeput(qp) after use.