Answer in brief
CVE-2026-72469 records a Unknown severity vulnerability in xprtrdma: Fix ep kref imbalance on ADDR_CHANGE. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=2acc5cae292355f5f18ad377a2a966e7f03c8fec <cfd1bab66b042da7a778786685125656c695931b || >=2acc5cae292355f5f18ad377a2a966e7f03c8fec <d0479c2b12974aa188b10d221a5770126b118b6d || >=2acc5cae292355f5f18ad377a2a966e7f03c8fec <ffc07790539736a5d029f6a3c966b46c529f93a8 || >=2acc5cae292355f5f18ad377a2a966e7f03c8fec <af9b65b29af341932625c4283dc7a23cdb62688a || 2fcbf07a4f23174a45e015b62a8e42ddbc2e53ef || >=5.7.9 <5.8 | cfd1bab66b042da7a778786685125656c695931b, d0479c2b12974aa188b10d221a5770126b118b6d, ffc07790539736a5d029f6a3c966b46c529f93a8, af9b65b29af341932625c4283dc7a23cdb62688a, 5.8 |
| Linux/Linuxgeneric | 5.8 | Not reported |
Published upstream
Aug 15, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 15, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 15, 2026
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.
Quoted source text, attributed separately from HOL analysis.
Answer in brief
CVE-2026-72469 records a Unknown severity vulnerability in xprtrdma: Fix ep kref imbalance on ADDR_CHANGE. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=2acc5cae292355f5f18ad377a2a966e7f03c8fec <cfd1bab66b042da7a778786685125656c695931b || >=2acc5cae292355f5f18ad377a2a966e7f03c8fec <d0479c2b12974aa188b10d221a5770126b118b6d || >=2acc5cae292355f5f18ad377a2a966e7f03c8fec <ffc07790539736a5d029f6a3c966b46c529f93a8 || >=2acc5cae292355f5f18ad377a2a966e7f03c8fec <af9b65b29af341932625c4283dc7a23cdb62688a || 2fcbf07a4f23174a45e015b62a8e42ddbc2e53ef || >=5.7.9 <5.8 | cfd1bab66b042da7a778786685125656c695931b, d0479c2b12974aa188b10d221a5770126b118b6d, ffc07790539736a5d029f6a3c966b46c529f93a8, af9b65b29af341932625c4283dc7a23cdb62688a, 5.8 |
| Linux/Linuxgeneric | 5.8 | Not reported |
Published upstream
Aug 15, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 15, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 15, 2026
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.
Quoted source text, attributed separately from HOL analysis.