Linux Kernel CVE-2026-93224

Requires a Linux host running the kernel NFS server with RDMA transport (svcrdma / NFS-over-RDMA) enabled and backed by RDMA-capable hardware (InfiniBand or RoCE) - a non-default, specialized deployment. Exploitation depends on svc_rdma_accept() taking its errout path before rpcrdma_rn_register() succeeds, i.e. a connection-setup/allocation failure during accept; this internal error condition is not straightforwardly forced by a remote client, which is the primary limiting factor. There is no authentication or user-interaction requirement beyond the ability to drive RDMA connection attempts to the server on the fabric.

This is a Linux kernel error-path bug in the svcrdma (server-side RDMA/NFS-over-RDMA) transport, not a directly weaponizable remote-code flaw. The NVD CVSS 3.1 vector (AV:N/AC:H/PR:N/UI:N/C:H/I:H/A:H = 8.1) appears substantially overstated: the description details a refcount/xarray corruption and object leak, not any confidentiality primitive, so C:H/I:H are hard to justify - the realistic impact is memory corruption and resource exhaustion (crash/DoS), i.e. C:N/I:L/A:H. There is no EPSS score, no CISA KEV listing, and no public proof-of-concept, so all exploitation signals are absent. The vulnerability only triggers when svc_rdma_accept() takes its error path BEFORE rpcrdma_rn_register() succeeds - an internal allocation/connection-setup failure that is not cleanly attacker-controlled, which is consistent with the AC:H already in the vector but contradicts PR:N/AV:N in a way that overstates reach (RDMA fabric access, not arbitrary Internet reach). Net: a legitimate correctness/hardening fix worth patching on NFS/RDMA servers, but far below the 'critical' urgency the 8.1 implies. VERIFY: the CWE is 'N/A' in the input and the tag says 'Information Disclosure', both of which conflict with the actual mechanism (CWE-416/667/911 memory corruption + leak).

An attacker (or a faulty client) repeatedly initiates RDMA connections to an NFS-over-RDMA server such that svc_rdma_accept() fails after partial setup; each failed accept erases another transport's xarray slot 0 and performs an unmatched kref_put on an unrelated rpcrdma_device, corrupting refcounts and leaking a svcxprt_rdma plus its pinned net namespace. Sustained failures cause resource exhaustion and potential use-after-free of other transports, degrading or crashing the server. No public exploit code exists, and the error path is difficult to trigger deterministically from the network.