CVE-2026-89543: sunrpc: fix use-after-free in __rpc_clnt_handle_event and __rpc_clnt_remove_pipedir
In the Linux kernel, the following vulnerability has been resolved:
sunrpc: fix use-after-free in rpcclnthandleevent and rpcclntremovepipedir
Normal client creation goes through rpcsetuppipedir(), which records clnt->pipefssb, but the mount-event path in rpcclnthandleevent() calls rpcsetuppipedirsb() directly and never refreshes that field. The umount path also removes the directory without clearing clnt->pipefssb.
After a late pipefs mount or any remount, rpcclntremovepipedir() compares the current superblock against a stale pipefssb pointer and skips cleanup, leaving pipefs dentries whose inode private data still points at a freed rpcclnt, leading to a potential use-after-free during subsequent rpcinfoopen() or rpcshowinfo() calls.
Fix this by properly updating clnt->pipefssb upon mount events and clearing it during unmount or failure paths.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Linux kernelto a version that resolves this vulnerability.Patch sunrpc: fix use-after-free in __rpc_clnt_handle_event and __rpc_clnt_remove_pipedir
Event History
Frequently Asked Questions
Which systems are exposed to this use-after-free condition?
Linux kernel systems using SUNRPC clients that encounter a late pipefs mount or a pipefs remount are exposed. The stale pipefs superblock tracking can leave pipefs entries associated with an RPC client after that client has been freed.
What action or condition is needed to trigger the issue?
The condition requires pipefs mount-event or remount handling to leave clnt->pipefs_sb stale, followed by RPC client directory cleanup being skipped. A subsequent rpc_info_open() or rpc_show_info() access to the remaining pipefs dentries can then dereference the freed RPC client.
How can administrators tell whether the vulnerable state may already exist?
A potentially affected state involves pipefs dentries that remain after an RPC client has been removed, particularly after late pipefs mounts or remounts. The provided data does not specify a user-space diagnostic or log signature.
What is the mitigation if an update cannot be applied immediately?
The provided information does not identify a complete workaround. Reducing late pipefs mount and remount activity may avoid the described stale-pointer path, but this is not stated as a supported mitigation.