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.
CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
CVSS Score: 9.8
AV:N - The 9p RDMA client processes RDMA receive completions and CM disconnect events from the remote peer in recv_done() and p9_cm_event_handler(); a malicious or compromised 9p server over RoCE/iWARP can trigger err_out and concurrent teardown without local access.
AC:L - The attacker controls both sides of the race by sending malformed 9p RDMA replies to drive recv_done() into err_out while forcing disconnects and concurrent rdma_request() error paths; no uncontrollable memory layout or rare victim state is required.
PR:N - A remote malicious 9p RDMA server needs no credentials on the victim kernel; HPC clusters and virtio-9p backends with persistent trans=rdma mounts let the server alone time malformed replies against in-flight client requests.
UI:N - No per-attack victim action is needed on existing 9p RDMA mounts—automated workloads, parallel I/O, and server-initiated RDMA disconnects concurrently reach recv_done() and rdma_request() during normal filesystem operation.
S:U - Impact is kernel heap corruption and local privilege escalation within the victim kernel security domain; UAF on p9_req_t during RDMA teardown does not cross VM, container, or IOMMU isolation boundaries.
C:H - Lost FLUSHING state transitions corrupt the connection teardown state machine and cause use-after-free on RDMA request (p9_req_t) objects; UAF provides attacker-influenced freed-heap contents usable for arbitrary kernel memory disclosure.
I:H - Corrupted rdma->state frees in-flight p9_req_t structures while send_done() and p9_client_cb() still hold references, enabling heap grooming and arbitrary kernel write or control-flow hijack primitives.
A:H - Use-after-free during RDMA request teardown causes kernel oops or panic when dangling p9_req_t objects are accessed, and state-machine corruption alone can hang or crash the 9p RDMA transport.
| Attack Vector |
Network |
Scope |
Unchanged |
| Attack Complexity |
Low |
Confidentiality Impact |
High |
| Privileges Required |
None |
Integrity Impact |
High |
| User Interaction |
None |
Availability Impact |
High |
AV:N - The 9p RDMA client processes RDMA receive completions and CM disconnect events from the remote peer in recv_done() and p9_cm_event_handler(); a malicious or compromised 9p server over RoCE/iWARP can trigger err_out and concurrent teardown without local access.
AC:L - The attacker controls both sides of the race by sending malformed 9p RDMA replies to drive recv_done() into err_out while forcing disconnects and concurrent rdma_request() error paths; no uncontrollable memory layout or rare victim state is required.
PR:N - A remote malicious 9p RDMA server needs no credentials on the victim kernel; HPC clusters and virtio-9p backends with persistent trans=rdma mounts let the server alone time malformed replies against in-flight client requests.
UI:N - No per-attack victim action is needed on existing 9p RDMA mounts—automated workloads, parallel I/O, and server-initiated RDMA disconnects concurrently reach recv_done() and rdma_request() during normal filesystem operation.
S:U - Impact is kernel heap corruption and local privilege escalation within the victim kernel security domain; UAF on p9_req_t during RDMA teardown does not cross VM, container, or IOMMU isolation boundaries.
C:H - Lost FLUSHING state transitions corrupt the connection teardown state machine and cause use-after-free on RDMA request (p9_req_t) objects; UAF provides attacker-influenced freed-heap contents usable for arbitrary kernel memory disclosure.
I:H - Corrupted rdma->state frees in-flight p9_req_t structures while send_done() and p9_client_cb() still hold references, enabling heap grooming and arbitrary kernel write or control-flow hijack primitives.
A:H - Use-after-free during RDMA request teardown causes kernel oops or panic when dangling p9_req_t objects are accessed, and state-machine corruption alone can hang or crash the 9p RDMA transport.
CVSS 3.1