CVE-2026-53397

In the Linux kernel, the following vulnerability has been resolved:

nfsd: fix posix_acl leak on SETACL decode failure

nfsaclsvc_decode_setaclargs() and nfs3svc_decode_setaclargs() each

call nfs_stream_decode_acl() twice, first for NFS_ACL and then for

NFS_DFACL. Each successful call transfers ownership of a freshly

allocated posix_acl into argp->acl_access or argp->acl_default. If

the first call succeeds but the second fails, the decoder returns

false and argp->acl_access is left dangling.

ACLPROC2_SETACL.pc_release was wired to nfssvc_release_attrstat and

ACLPROC3_SETACL.pc_release was wired to nfs3svc_release_fhandle.

Both only call fh_put() and have no knowledge of the ACL fields on

argp. The posix_acl_release() pairs sat at the out: labels inside

nfsacld_proc_setacl() and nfsd3_proc_setacl(), but svc_process()

skips pc_func when pc_decode returns false, so that cleanup is

unreachable on decode failure:

svc_process_common()

pc_decode() /* decode_setaclargs: false */

/* pc_func skipped */

pc_release() /* fh_put only -- ACLs leaked */

The orphaned posix_acl is leaked for the lifetime of the server.

Fix by adding nfsaclsvc_release_setacl() and nfs3svc_release_setacl(),

which release both argp->acl_access and argp->acl_default in addition

to fh_put(), and wiring them as pc_release for their respective SETACL

procedures. pc_release runs on every path svc_process() takes after

decode, including decode failure, so the posix_acl_release() pairs are

removed from the proc functions' out: labels to keep ownership in one

place. This matches the existing release_getacl() pattern used by

the sibling GETACL procedures.