CVE-2026-89534: svcrdma: Clear sc_cm_id when ADDR_CHANGE replacement fails
In the Linux kernel, the following vulnerability has been resolved:
svcrdma: Clear sccmid when ADDRCHANGE replacement fails
When svcrdmalistenhandler() handles RDMACMEVENTADDRCHANGE, it creates a replacement listener cmid and returns 1, telling the CM core to destroy the old one. If the replacement allocation fails, sccmid still points at the old cmid that the CM core is about to destroy. Any subsequent dereference of sccmid -- such as svcrdmadetach()'s rdmadisconnect() call -- is a use-after-free.
NULL sccmid on the failure path and guard svcrdmadetach()'s rdmadisconnect() call against NULL so that the listener can be torn down safely when the server shuts down.
Affected Software
Event History
Frequently Asked Questions
What conditions are required to trigger the use-after-free?
The RDMA server listener must receive an RDMA_CM_EVENT_ADDR_CHANGE event, and creation of the replacement listener cm_id must then fail. A later teardown path that dereferences the stale sc_cm_id, such as svc_rdma_detach() calling rdma_disconnect(), can trigger the use-after-free.
What happens if the server is shut down after the replacement listener allocation fails?
Before the fix, sc_cm_id can still reference the old listener cm_id after the CM core destroys it, making teardown unsafe. The fix clears sc_cm_id on that failure path and skips rdma_disconnect() when sc_cm_id is NULL, allowing safe listener teardown.
How can I determine whether a system contains the fix?
Check whether the kernel includes either referenced stable commit 673e358ab7c11f8cec223c6a36a793056a67facd or 01500306e1d50de7ca7a2cdcdfa28ac0523eb747. The corrected code must clear sc_cm_id when replacement listener creation fails during ADDR_CHANGE handling and must guard the detach-time rdma_disconnect() call against a NULL sc_cm_id.