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.

An update of the linux package has been released.

There are packages installed that are affected by a vulnerability referenced in the following CVE:

  - 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. (CVE-2026-93224)

The Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

  - 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. (CVE-2026-93224)

Note that Nessus relies on the presence of the package as reported by the vendor.

ID	Name	Product	Family	Type	Severity
376443	Ubuntu 24.04 LTS / 26.04 LTS : Linux kernel vulnerabilities (USN-8959-1)	Nessus	Ubuntu Local Security Checks	Local	high
375048	Photon OS 5.0: Linux PHSA-2026-5.0-92-0999	Nessus	PhotonOS Local Security Checks	Local	high
375011	Photon OS 5.0: Linux PHSA-2026-5.0-91-0999	Nessus	PhotonOS Local Security Checks	Local	high
475532	Google: sys-kernel/cchost-kernel-6_18, sys-kernel/csql-kernel-6_18, sys-kernel/lakitu-kernel-6_18, sys-kernel/lakitu-nc-kernel-6_18: security update to 19999.44.106	Tenable Cloud Security	Google COS Security Checks	Local	high
475532	Google: sys-kernel/cchost-kernel-6_18, sys-kernel/csql-kernel-6_18, sys-kernel/lakitu-kernel-6_18, sys-kernel/lakitu-nc-kernel-6_18: security update to 19999.44.106	Tenable Self-Hosted Container Security	Google COS Security Checks	Local	high
364137	Oracle Linux 10 / 9 : Unbreakable Enterprise kernel (ELSA-2026-500374)	Nessus	Oracle Linux Local Security Checks	Local	high
362907	Debian dla-4817 : ata-modules-6.12.107+deb12-armmp-di - security update	Nessus	Debian Local Security Checks	Local	high
351155	Debian dsa-6528 : ata-modules-6.12.111+deb13-armmp-di - security update	Nessus	Debian Local Security Checks	Local	high
350098	Linux Distros Unpatched Vulnerability : CVE-2026-93224	Nessus	Misc.	Local	high

Detections

Analytics

CVE-2026-93224

high

Tenable Plugins

high

high

high

high

high

high

high

high

high