Linux kernel nfsd: use-after-free on stale ACL pointers when fetching the default ACL fails

Impact

When the in-kernel NFS server fails to fetch acl_default, it releases both acl_access and acl_default but leaves acl_access still pointing at the freed posix_acl. The release path in nfs3svc_release_getacl then drops a reference on freed memory, producing a refcount underflow warning and a use-after-free; on a kernel built with panic_on_warn the node panics outright. For operators this is an availability problem on the fileserver, not a tenant-to-tenant escape: a host exporting NFS to the cluster can be crashed by a client issuing an NFSv3 GETACL against a path where the default-ACL lookup fails. On fleets where home directories, datasets or checkpoints come off a Linux NFS server, losing that server stalls every job that was reading from it, which is far more expensive than the single node. GPU compute nodes that only mount NFS are unaffected - the bug is in the server, nfsd.

Who can reach it

Any NFS client that can reach the server's nfsd and issue an NFSv3 GETACL request - so anyone on the storage network, within whatever export and authentication policy the server enforces. Not reachable at all on hosts that do not run the in-kernel NFS server.

What to do

Take the stable kernel update containing the fix (nfsd: clear acl_access/acl_default after releasing them) from your distribution, or the upstream stable commits. Applying it means rebooting the NFS server, which for a shared fileserver has to be coordinated with every job that mounts it - this is a storage maintenance window, not a per-GPU-node drain. If a reboot cannot be scheduled, unexporting NFSv3 (serving v4 only) or tightening export access to trusted clients narrows the reach in the meantime.

References

Related entries

• Linux kernel (drivers/nvme/target): The target disables a namespace without waiting for in-flight I/O to drain, so aCVE-2025-21850 · Linux kernel (drivers/nvme/target)Critical
• Linux kernel - NVMe/TCP host (initiator), drivers/nvme/host/tcp.c: Nvme_tcp_recv_pdu() did not validate the PDU headerCVE-2025-21927 · Linux kernel - NVMe/TCP host (initiator), drivers/nvme/host/tcp.cCritical
• Xen: guest can NULL-dereference the viridian reference TSC update path and crash the hostCVE-2025-27466 · Xen viridian enlightenments (reference TSC area update)Critical
• Linux kernel (net/tls): The strparser kept a stale reference to an skb that TCP had already coalesced away, and theCVE-2025-38471 · Linux kernel (net/tls)Critical
• Linux kernel (net/smc): The SMC listen worker keeps touching the SMC socket after smc_listen_out() has handed it offCVE-2025-38734 · Linux kernel (net/smc)Critical
• Linux kernel (net/tls): A zero-length record already sitting on the rx_list breaks the invariant that zero-copy decryptCVE-2025-39682 · Linux kernel (net/tls)Critical