In the Linux kernel, the following vulnerability has been resolved:
nfsd: fix posix_acl leak on SETACL decode failure
nfsaclsvcdecodesetaclargs() and nfs3svcdecodesetaclargs() each call nfsstreamdecodeacl() twice, first for NFSACL and then for NFSDFACL. Each successful call transfers ownership of a freshly allocated posixacl into argp->aclaccess or argp->acldefault. If the first call succeeds but the second fails, the decoder returns false and argp->acl_access is left dangling.
ACLPROC2SETACL.pcrelease was wired to nfssvcreleaseattrstat and ACLPROC3SETACL.pcrelease was wired to nfs3svcreleasefhandle. Both only call fhput() and have no knowledge of the ACL fields on argp. The posixaclrelease() pairs sat at the out: labels inside nfsacldprocsetacl() and nfsd3procsetacl(), but svcprocess() skips pcfunc when pcdecode 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 nfsaclsvcreleasesetacl() and nfs3svcreleasesetacl(), which release both argp->aclaccess and argp->acldefault in addition to fhput(), and wiring them as pcrelease for their respective SETACL procedures. pcrelease runs on every path svcprocess() takes after decode, including decode failure, so the posixaclrelease() 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.
{
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/53xxx/CVE-2026-53397.json",
"cna_assigner": "Linux"
}