Database/Control plane, storage & DevOps

Linux kernel NFSD: copynotify stateid outlives its parent open, corrupting the laundromat list

CVSS 8.8CVE-2025-40273Control plane, storage & DevOpscurated

Impact

An NFSv4.2 client that does OPEN, then COPY_NOTIFY on that stateid, then reboots and forces expiry of its own prior state via CREATE_SESSION, leaves a copynotify stateid attached to an open state that is being freed. The server hits a WARN at nfs4state.c:1550 and, once the laundromat later frees the orphaned copynotify state, walks a corrupted list - the record shows an Oops in __list_del_entry_valid_or_report() from the nfsd4 laundromat workqueue. For a cluster whose home directories, datasets or checkpoints come off a Linux NFS server, that is a remote client crashing the file server, which stalls every GPU job holding a mount. The crash is in kernel context, so recovery is a server reboot, not a daemon restart.

Who can reach it

Network, from any host allowed to mount the export and authenticate as an NFSv4.2 client - the sequence uses only legitimate operations on the client's own state. No server-side privilege needed.

What to do

Update the NFS server to a stable kernel carrying the linked fix and reboot it; nfsd is in-kernel, so the fix cannot be applied by restarting a userspace daemon. The record names no configuration workaround, though exports that do not offer NFSv4.2 server-side copy are not reachable through COPY_NOTIFY. Plan the reboot as a storage outage - clients with hard mounts will block rather than fail.

References

https://nvd.nist.gov/vuln/detail/CVE-2025-40273 https://git.kernel.org/stable/c/29fbb3ad4018ca2b0988fbac76f4c694cc6d7e66 https://git.kernel.org/stable/c/4aa17144d5abc3c756883e3a010246f0dba8b468 https://git.kernel.org/stable/c/839f56f626723f36904764858467e7a3881b975d

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.