CVE-2026-89535: svcrdma: Reorder rpcrdma_rn_unregister before rdma_destroy_id
In the Linux kernel, the following vulnerability has been resolved:
svcrdma: Reorder rpcrdmarnunregister before rdmadestroyid
svcrdmafree() caches rdma->sccmid->device before teardown, then calls rdmadestroyid(sccmid) which frees the cmid. rpcrdmarnunregister() follows, but between those two calls the transport's scrn entry is still installed in the device's rdxa. A concurrent ibunregisterdevice walk can dispatch svcrdmaxprtdone() against the now-freed sccmid.
Move rpcrdmarnunregister() before rdmadestroyid() so the transport's notification entry is removed from the xarray before the cmid it references is destroyed.
Also guard the sccmid dereference with a NULL check: the following patches introduce paths that reach svcrdmafree() with sccmid == NULL (listener create failure, ADDRCHANGE replacement failure).
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Reorder cleanup calls so that rpcrdma_rn_unregister() is executed before rdma_destroy_id(), preventing svc_rdma_free() from using a cached rdma->sc_cm_id->device after sc_cm_id has been destroyed.
Linux kernel (svcrdma / rpcrdma_rn_unregister) Function call order in svcrdma = rpcrdma_rn_unregister() before rdma_destroy_id() - Compensating control
Guard the sc_cm_id dereference with a NULL check so that sc_cm_id is tested for NULL before accessing it (as described: “Also guard the sc_cm_id dereference with a NULL check”).
Event History
Frequently Asked Questions
What condition is required to trigger the race?
A concurrent RDMA device-unregistration walk must occur after rdma_destroy_id() frees the transport's cm_id but before the transport's notification entry is removed from the device xarray. That walk can then invoke svc_rdma_xprt_done() with a reference to the freed sc_cm_id.
What failure modes are additionally handled by the fix?
The fix adds a NULL check before dereferencing sc_cm_id in svc_rdma_free(). This covers paths where listener creation fails or an ADDR_CHANGE replacement fails and svc_rdma_free() is reached with sc_cm_id set to NULL.
How does the fix prevent the use-after-free?
It unregisters the transport notification entry with rpcrdma_rn_unregister() before calling rdma_destroy_id(). Removing the entry first prevents device-unregistration notification processing from finding a transport whose cm_id has already been destroyed.