CVE-2026-72491net/9p: fix race condition on rdma->state in trans_rdma.c
Updated under an hour ago ()
Does this affect you?
It affects Linux. Add what you run to find out whether that includes you.
No exploitation reported and no EPSS estimate yet.
Do this next
Free account, 1 product
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
- 9.8 CRITICAL (v3.1, CNA)CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
- Weakness (CWE)
- Not given
- Known exploited
- Not in CISA's KEV catalog
- EPSS (exploitation in the next 30 days)
- Not loaded for this CVE
- Assigned by
- Linux
- NVD analysis
- Received
- Record last updated
- Oct 16, 2026
- First seen by InfoSec Signals
- Oct 9, 2026
Affected products
Linux Linux linux:linux (from the name) | 473c7dd1d7b59ff8f88a5154737e3eac78a96e5b builds before 4cee2b8766045059d5e0b8114837b4a8efe827ac; from 473c7dd1d7b59ff8f88a5154737e3eac78a96e5b before 5424138848eb7d7d8a7196676e90a2cbf2142454; from 473c7dd1d7b59ff8f88a5154737e3eac78a96e5b before 3970a19a80de530b801b6256354d4a529a9a2d6c; 473c7dd1d7b59ff8f88a5154737e3eac78a96e5b builds before 8aadc136d8e8d8fc95d7982d213cfe2234dfcf2b; 473c7dd1d7b59ff8f88a5154737e3eac78a96e5b builds before 151f8cf5b23d8a534d884432a82a6d54d5a61989; 473c7dd1d7b59ff8f88a5154737e3eac78a96e5b builds before 13bf9879b778b2f4b260b45bed18f31806120d1e; from 473c7dd1d7b59ff8f88a5154737e3eac78a96e5b before ebbcbe5c0db215feecc17def06178da443f4eea6; 473c7dd1d7b59ff8f88a5154737e3eac78a96e5b builds before 7d54894a1ee265a72d70f7cae1da6cc774cccc71; and 8 more ranges | CNA record |
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
The CVE record on cve.org NVD's entry
The CVE record is authoritative. Products marked “from the name” were identified from the CNA's free-text names, not a CPE, and are matched less certainly. This product uses the NVD API but is not endorsed or certified by the NVD.