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

recv_done() and p9_cm_event_handler(), 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 = P9_RDMA_FLUSHING without acquiring req_lock

- p9_cm_event_handler() modifies rdma->state at multiple points

(ADDR_RESOLVED, ROUTE_RESOLVED, ESTABLISHED, CLOSED) without

req_lock

- rdma_request() uses spin_lock_irqsave(&rdma->req_lock, 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

recv_done() and p9_cm_event_handler(), matching the pattern already

used in rdma_request(). Use spin_lock_irqsave/spin_unlock_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

rdma_request and recv_done/CM handler) on rdma->state with proper

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

transitions.