CVE-2026-72491

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

net/9p: fix race condition on rdma->state in trans_rdma.c

The rdma->state field is modified without holding req_lock in both

recvdone() and p9cmeventhandler(), while rdma_request() accesses

the same field under the req_lock spinlock. This inconsistent locking

creates a race condition:

• recv_done() running in softirq completion context sets

  rdma->state = P9RDMAFLUSHING without acquiring req_lock

• p9cmevent_handler() modifies rdma->state at multiple points

  (ADDRRESOLVED, ROUTERESOLVED, ESTABLISHED, CLOSED) without

  req_lock

• rdmarequest() uses spinlockirqsave(&rdma->reqlock, flags) to

  protect the read-modify-write of rdma->state

The race can cause lost state transitions: recv_done() or the CM

event handler could set state to FLUSHING/CLOSED while rdma_request()

is concurrently checking or modifying state under the lock, leading to

the FLUSHING transition being silently overwritten by CLOSING. This

corrupts the connection state machine and can cause use-after-free on

RDMA request objects during teardown.

Fix by adding req_lock protection to all rdma->state modifications in

recvdone() and p9cmeventhandler(), matching the pattern already

used in rdmarequest(). Use spinlockirqsave/spinunlock_irqrestore

in the CM event handler since it can race with recv_done() which runs

in softirq context.

Tested with a kernel module that races two threads (simulating

rdmarequest and recvdone/CM handler) on rdma->state with proper

locking: 5.5M+ FLUSHING writes over 27M iterations with 0 lost

transitions.