CVE-2026-93224
What it is
In the Linux kernel, the following vulnerability has been resolved: svcrdma: Fix unmatched rn_unregister on failed accept When svc_rdma_accept() takes the errout path before rpcrdma_rn_register() has succeeded, the existing cleanup block calls rpcrdma_rn_unregister(dev, &newxprt->sc_rn) unconditionally. svcxprt_rdma is kzalloc'd, so on that path sc_rn.rn_index is 0 and sc_rn.rn_done is NULL; the unregister therefore xa_erase()s another caller's slot 0 and performs an unmatched kref_put() on the rpcrdma_device's rd_kref. The same errout also brackets the cleanup with svc_xprt_get()/ svc_xprt_put() around the kref_init() birth reference. The kref goes 1 -> 2 -> 1 and never reaches 0, so the svcxprt_rdma (and the net/ns_tracker it pinned) is leaked on every failed accept. rpcrdma_rn_register() writes rn->rn_done last, only after xa_alloc() and kref_get() have both succeeded, so rn_done == NULL is a natural "never registered" sentinel. Guard rpcrdma_rn_unregister() with an early return when rn_done is NULL, and clear rn_done before the matching xa_erase() so a repeated unregister is also a no-op. With that guard in place, the accept errout drops the kref_init() birth reference via svc_xprt_put(), which dispatches svc_rdma_free(). Teardown of sc_qp, sc_sq_cq, sc_rq_cq, and sc_pd runs under existing IS_ERR/NULL guards in svc_rdma_free(); sc_rn is covered by the new rn_done sentinel; sc_cm_id is non-NULL on every errout path because svc_rdma_accept() dereferences it above the first goto errout. svc_xprt_free() drops the module reference associated with the freed transport, and svc_handle_xprt() drops its pre-acquired reference when ->xpo_accept() returns NULL. Take a replacement module reference before svc_xprt_put() so the two module_put()s remain balanced. The rn_done guard also covers svc_rdma_free()'s non-listener call to rpcrdma_rn_unregister() for transports whose register attempt failed or never ran.
At a glance
- Exploitability
- Can be exploited over the network without logging in. High risk of data exposure, data tampering, service disruption.
- Exploit odds
- 0.4% chance of exploitation in the next 30 days (EPSS).
- Fix
- No patch or advisory is linked yet. Look at mitigations or restrict exposure.
Timeline
- ReservedThe CVE id was reserved by its CNA
- PublishedDisclosed publicly on CVE.org and NVD
- Last updatedMost recent change to the record
Why it ranks here
- Exploited in the wild: no, CISA does not list it.
- Exploit odds: 0.4% in the next 30 days (EPSS).
- Severity: 8.1 HIGH (CVSS).
- Fix: none linked yet, which raises it.
Details
- Published
- Last modified
- Exploit probability
- 0.4% · EPSS, next 30 days
- Record status
- Received
Attack profile CVSS 3.1 · 8.1
- Attack vector
- Network
- Complexity
- High
- Privileges needed
- None
- User interaction
- None
- Scope
- Unchanged
- Confidentiality
- High
- Integrity
- High
- Availability
- High
Raw vector
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H
Is it in your code?
Hand this to your coding agent. It searches your project for the affected products and checks versions. Nothing leaves your machine.
Read https://cve-list.com/agent/cve/CVE-2026-93224.md and follow it. Check whether this project is affected by CVE-2026-93224. Read only. Don't change anything and don't upload my code. Tell me yes, no or not sure, with the file as proof.
