CVE-2026-89672: nfsd: gate nfs2 setacl by argp->mask
In the Linux kernel, the following vulnerability has been resolved:
nfsd: gate nfs2 setacl by argp->mask
The NFSACL v2 SETACL path shares the decoder convention used by its v3 sibling: nfsaclsvcdecodesetaclargs() fills in argp->aclaccess only when NFSACL is set in the request mask and argp->acldefault only when NFSDFACL is set, leaving the other pointer NULL because the argument buffer is zeroed up to pcargzero before decode.
nfsacldprocsetacl() then hands both pointers to setposixacl() unconditionally. setposixacl(idmap, dentry, type, NULL) is the VFS "remove this ACL type" operation, so an omitted arm is indistinguishable from an explicit request to delete that ACL. A SETACL carrying only NFSACL silently strips the directory's default ACL; mask=0 strips both.
This is the same defect just fixed in nfsd3procsetacl(); apply the same remedy. Gate each setposixacl() call on its mask bit and initialize error to 0 so that a request with neither bit set leaves the on-disk ACLs untouched and returns success. The outdroplock path and the unconditional posixaclrelease() in nfsaclsvcreleasesetacl() already tolerate the skipped arms.
Affected Software
Event History
Frequently Asked Questions
Who is exposed to this issue?
Systems using the Linux kernel NFS server ACL v2 SETACL path are exposed. The impact is on directory POSIX ACLs processed through NFSACL v2 requests.
What does an attacker need to do to trigger the unintended ACL removal?
An attacker needs to send an NFSACL v2 SETACL request with selected mask bits omitted. A request containing only NFS_ACL can remove a directory's default ACL, while a request with mask=0 can remove both ACL types.
How can I tell whether ACLs may already have been affected?
Inspect directory access and default POSIX ACLs on NFS server exports that accept NFSACL v2 SETACL requests. Directories whose default ACLs were unexpectedly removed, or whose access and default ACLs are both absent after such requests, may have been affected.
What is the effect of the resolved behavior?
SETACL operations are performed only for ACL types explicitly indicated by the request mask. A request with neither ACL mask bit set leaves on-disk ACLs unchanged and returns success.