CVE-2026-72469
Last modified
CVE-2026-72469 is a high-severity vulnerability rated 8.8/10 on the CVSS scale. 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. EPSS estimates a 0.20% chance of exploitation in the next 30 days.
Description
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.
Metrics
CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Affected Software
Source: CNA advisory (CVE.org). NVD analysis pending.
| Vendor | Product | Versions |
|---|---|---|
| Linux | Linux | >= 2acc5cae292355f5f18ad377a2a966e7f03c8fec, < cfd1bab66b042da7a778786685125656c695931b; >= 2acc5cae292355f5f18ad377a2a966e7f03c8fec, < d0479c2b12974aa188b10d221a5770126b118b6d; >= 2acc5cae292355f5f18ad377a2a966e7f03c8fec, < ffc07790539736a5d029f6a3c966b46c529f93a8; >= 2acc5cae292355f5f18ad377a2a966e7f03c8fec, < af9b65b29af341932625c4283dc7a23cdb62688a; 2fcbf07a4f23174a45e015b62a8e42ddbc2e53ef; >= 5.7.9, < 5.8 |
| Linux | Linux | 5.8 |
References
Timeline
- Published
- Last Modified
- Status
- Received
Frequently Asked Questions
What is CVE-2026-72469?
How severe is CVE-2026-72469?
How do I fix CVE-2026-72469?
How Strix Helps
- How Strix found a critical auth bypass in etcdStrix autonomously discovered a critical authentication bypass in etcd, later designated CVE-2026-33413.
- Autonomous PentestingAI agents that find and validate exploitable vulnerabilities like this one across your applications.
- PR ReviewsPentest every pull request so vulnerable code is caught before it ships to production.
- AI Penetration TestingHow AI-driven penetration testing continuously covers your attack surface.
Related CVEs from 2026
- CVE-2026-72463In the Linux kernel, the following vulnerability has been re…9.8
- CVE-2026-72464In the Linux kernel, the following vulnerability has been re…7.5
- CVE-2026-72465In the Linux kernel, the following vulnerability has been re…7.5
- CVE-2026-72466In the Linux kernel, the following vulnerability has been re…9.8
- CVE-2026-72467In the Linux kernel, the following vulnerability has been re…
- CVE-2026-72468In the Linux kernel, the following vulnerability has been re…
- CVE-2026-7247A vulnerability has been found in D-Link DI-8100 16.07.26A1.…7.3
- CVE-2026-72470In the Linux kernel, the following vulnerability has been re…7.8
- CVE-2026-72471In the Linux kernel, the following vulnerability has been re…7.1
- CVE-2026-72472In the Linux kernel, the following vulnerability has been re…9.8
- CVE-2026-72473In the Linux kernel, the following vulnerability has been re…9.8
- CVE-2026-72474In the Linux kernel, the following vulnerability has been re…
Are you affected by CVE-2026-72469?
Run a free Strix scan to check your systems for this vulnerability.
Scan your code nowSource: NVD / NIST
