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

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

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

The rdma->state field is modified without holding reqlock in both recvdone() and p9cmeventhandler(), while rdmarequest() accesses the same field under the reqlock spinlock. This inconsistent locking creates a race condition:

- recvdone() running in softirq completion context sets rdma->state = P9RDMAFLUSHING without acquiring reqlock

- p9cmeventhandler() modifies rdma->state at multiple points (ADDRRESOLVED, ROUTERESOLVED, ESTABLISHED, CLOSED) without reqlock

- rdmarequest() uses spinlockirqsave(&rdma->reqlock, flags) to protect the read-modify-write of rdma->state

The race can cause lost state transitions: recvdone() or the CM event handler could set state to FLUSHING/CLOSED while rdmarequest() 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 reqlock protection to all rdma->state modifications in recvdone() and p9cmeventhandler(), matching the pattern already used in rdmarequest(). Use spinlockirqsave/spinunlockirqrestore in the CM event handler since it can race with recvdone() 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.