CVE-2026-89545: sunrpc: defer rq_argp and rq_resp free until after RCU grace period
In the Linux kernel, the following vulnerability has been resolved:
sunrpc: defer rqargp and rqresp free until after RCU grace period
svcrqstfree() frees rqstp->rqargp and rqstp->rqresp synchronously via kfree(), but defers the rqstp struct free via kfreercu(). After svcexitthread() calls listdelrcu() and svcrqstfree(), there is a window where RCU readers that started before listdelrcu() can still traverse the thread list and find the rqstp. These readers (e.g. nfsdnlrpcstatusgetdumpit()) dereference rqstp->rqargp, which has already been freed — a use-after-free.
Fix this by moving the kfree of rqargp and rqresp into an explicit callrcu() callback alongside the struct free. Resources not accessed by RCU readers (bvec, buffer pages, scratch folio, authdata) remain synchronously freed.
Affected Software
Event History
Frequently Asked Questions
What kernel activity is required for this issue to occur?
The issue requires an RCU reader to traverse the service thread list after a thread has been removed with list_del_rcu() but before the reader's RCU grace period ends. The affected reader may then dereference the request's rq_argp after it has been freed.
Which components are implicated by the described race?
The race is in the kernel's sunrpc service request cleanup path, specifically svc_exit_thread() and svc_rqst_free(). The description identifies nfsd_nl_rpc_status_get_dumpit() as an example RCU reader that can access the freed request data.
What changes in the resolved code?
Freeing of rq_argp and rq_resp is deferred through an explicit call_rcu() callback, together with freeing the request structure. Other resources listed in the description, including bvec, buffer pages, scratch folio, and auth_data, continue to be freed synchronously because RCU readers do not access them.