svcrdma: Fix unmatched rn_unregister on failed accept
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
- Products
- Kernel
- Affected versions
- Not specified
- Fixed versions
- 6.12.109, 6.18.50, 7.2.4
- CVEs
- CVE-2026-93224
- Confirmed fixed CVEs
- Not specified
- Updated in this feed
- 8 Nov 2026, 02:44 UTC · Revision 1
Source evidence
svcrdma: Fix unmatched rn_unregister on failed accept
core-osv · Original sourcePublished 24 Sept 2026, 15:21 UTC
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
osv:CVE-2026-93224
Kernel
Fixed versions: 6.12.109, 6.18.50, 7.2.4
Complete source record
{
"id": "dde005ec76bd159b8d80ab1d1a4b4318b34a667535887b76a3d5c8198a645f07",
"url": "https://osv.dev/vulnerability/CVE-2026-93224",
"method": "structured",
"payload": {
"kind": "advisory",
"title": "svcrdma: Fix unmatched rn_unregister on failed accept",
"summary": "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 ",
"evidence": "osv:CVE-2026-93224",
"products": [
{
"name": {
"value": "Kernel",
"evidence": "/affected/1/package/name"
},
"prerequisites": [],
"fixed_versions": [
{
"value": "6.12.109",
"evidence": "/affected/1/ranges"
},
{
"value": "6.18.50",
"evidence": "/affected/1/ranges"
},
{
"value": "7.2.4",
"evidence": "/affected/1/ranges"
}
],
"affected_versions": []
}
],
"severity": "high",
"structured": {
"id": "CVE-2026-93224",
"aliases": [
"CVE-2026-93224"
],
"metrics": [
{
"type": "CVSS_V3",
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H"
}
],
"affected": [
{
"ranges": [
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "cb3cba0ec372fa7c5f5f5c12990bef02e458ab86"
},
{
"fixed": "0335800071a6dfdf7d21d729b5e7d8fa98936211"
}
]
},
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "8ac6fcae5dc0e801f1c82a83f5ae2c0a4db19932"
},
{
"fixed": "5aabe070c00e5bdf4ab150fb5f72ad5f266d6241"
},
{
"fixed": "45a444a17240f4fa2235f0dfd4a96fc80f1eb2c2"
},
{
"fixed": "26190394c64c9429481fc88a4738f70bb92fb352"
}
]
},
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "6.12.35"
},
{
"fixed": "6.12.109"
}
]
},
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "6.15.4"
},
{
"fixed": "6.16"
}
]
},
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "d310955106c358c8e1ea682defd8e21af44a6cba"
}
]
}
],
"versions": [
"v6.12.108",
"v6.12.107",
"v6.12.106",
"v6.12.105",
"v6.12.104",
"v6.12.103",
"v6.12.102",
"v6.12.101",
"v6.12.100",
"v6.12.99",
"v6.12.98",
"v6.12.97",
"v6.12.96",
"v6.12.95",
"v6.12.94",
"v6.12.93",
"v6.12.92",
"v6.12.91",
"v6.12.90",
"v6.12.89",
"v6.12.88",
"v6.12.87",
"v6.12.86",
"v6.12.85",
"v6.12.84",
"v6.12.83",
"v6.12.82",
"v6.12.81",
"v6.12.80",
"v6.12.79",
"v6.12.78",
"v6.12.77",
"v6.12.76",
"v6.12.75",
"v6.12.74",
"v6.12.73",
"v6.12.72",
"v6.12.71",
"v6.12.70",
"v6.12.69",
"v6.12.68",
"v6.12.67",
"v6.12.66",
"v6.12.65",
"v6.12.64",
"v6.12.63",
"v6.12.62",
"v6.12.61",
"v6.12.60",
"v6.12.59",
"v6.12.58",
"v6.12.57",
"v6.12.56",
"v6.12.55",
"v6.12.54",
"v6.12.53",
"v6.12.52",
"v6.12.51",
"v6.12.50",
"v6.12.49",
"v6.12.48",
"v6.12.47",
"v6.12.46",
"v6.12.45",
"v6.12.44",
"v6.12.43",
"v6.12.42",
"v6.12.41",
"v6.12.40",
"v6.12.39",
"v6.12.38",
"v6.12.37",
"v6.12.36",
"v6.12.35",
"v6.15.11",
"v6.15.10",
"v6.15.9",
"v6.15.8",
"v6.15.7",
"v6.15.6",
"v6.15.5",
"v6.15.4"
],
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-93224.json"
}
},
{
"ranges": [
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "0"
},
{
"fixed": "6.12.109"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.13.0"
},
{
"fixed": "6.18.50"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.16.0"
},
{
"fixed": "7.2.4"
}
]
}
],
"package": {
"name": "Kernel",
"ecosystem": "Linux"
},
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-93224.json"
}
}
],
"modified": "2026-10-28T02:30:53.001224105Z",
"provider": "osv",
"references": [
"https://git.kernel.org/stable/c/0335800071a6dfdf7d21d729b5e7d8fa98936211",
"https://git.kernel.org/stable/c/26190394c64c9429481fc88a4738f70bb92fb352",
"https://git.kernel.org/stable/c/45a444a17240f4fa2235f0dfd4a96fc80f1eb2c2",
"https://git.kernel.org/stable/c/5aabe070c00e5bdf4ab150fb5f72ad5f266d6241",
"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/93xxx/CVE-2026-93224.json",
"https://nvd.nist.gov/vuln/detail/CVE-2026-93224",
"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git"
],
"provider_metadata": {
"cna_assigner": "Linux",
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/93xxx/CVE-2026-93224.json"
}
},
"related_cves": [
{
"value": "CVE-2026-93224",
"evidence": "/id"
}
],
"security_relevant": true,
"severity_evidence": "/severity/0/score"
},
"source_id": "core-osv",
"document_id": 521904,
"published_at": "2026-09-24T15:21:10.542+00:00"
}