CVE-2026-72469xprtrdma: Fix ep kref imbalance on ADDR_CHANGE
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: xprtrdma: Fix ep kref imbalance on ADDR_CHANGE rpcrdma_cm_event_handler() falls through to the disconnected: label on RDMA_CM_EVENT_ADDR_CHANGE and calls rpcrdma_ep_put() with no matching get when the event arrives before RDMA_CM_EVENT_ESTABLISHED. The kref then underflows during connect teardown and rpcrdma_xprt_disconnect() operates on a freed ep. Reference counts across a normal connection lifecycle: rpcrdma_ep_create() kref_init ->1 rpcrdma_xprt_connect() ep_get ->2 (before post_recvs) RDMA_CM_EVENT_ESTABLISHED ep_get ->3 RDMA_CM_EVENT_DISCONNECTED ep_put ->2 rpcrdma_xprt_drain() ep_put ->1 rpcrdma_xprt_disconnect() tail ep_put ->0 (ep_destroy) The connect-time get in rpcrdma_xprt_connect(), taken just before rpcrdma_post_recvs() "while there are outstanding Receives," is balanced by rpcrdma_xprt_drain. ADDR_CHANGE before ESTABLISHED has no get to consume, so its put drops the count to 1 and the drain put then frees the ep while rpcrdma_xprt_disconnect() still holds a pointer to it. Fix by dispatching on the prior re_connect_status via xchg(): for prev == 0 (pre-ESTABLISHED) wake the connect waiter and return with no put; for prev == 1 call rpcrdma_force_disconnect() and return. The case-1 arm relies on the subsequent RDMA_CM_EVENT_DISCONNECTED event -- reliably delivered when rdma_disconnect() is called on a still-connected cm_id -- to balance the ESTABLISHED get; rpcrdma_xprt_drain() continues to balance only that connect-time get. Any other prior value means teardown is already in flight.
- CVSS
- 8.8 HIGH (v3.1, CNA)CVSS:3.1/AV:A/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) | from 2acc5cae292355f5f18ad377a2a966e7f03c8fec before cfd1bab66b042da7a778786685125656c695931b; from 2acc5cae292355f5f18ad377a2a966e7f03c8fec before d0479c2b12974aa188b10d221a5770126b118b6d; from 2acc5cae292355f5f18ad377a2a966e7f03c8fec before ffc07790539736a5d029f6a3c966b46c529f93a8; from 2acc5cae292355f5f18ad377a2a966e7f03c8fec before af9b65b29af341932625c4283dc7a23cdb62688a; 2fcbf07a4f23174a45e015b62a8e42ddbc2e53ef; from 5.7.9 before 5.8 | CNA record |
References
- https://git.kernel.org/stable/c/cfd1bab66b042da7a778786685125656c695931b
- https://git.kernel.org/stable/c/d0479c2b12974aa188b10d221a5770126b118b6d
- https://git.kernel.org/stable/c/ffc07790539736a5d029f6a3c966b46c529f93a8
- https://git.kernel.org/stable/c/af9b65b29af341932625c4283dc7a23cdb62688a
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.