CVE-2026-89672
Critical · 9.1CVSS
9.1
EPSS
0.5%
Published
Sep 11, 2026
CISA due date
—
Cloudanix analysis
A server bug could let outsiders quietly delete the permission rules on shared files without needing any login.
- Exploitation
- Remote Unauthenticated
- Attacker needs
- None
- Complexity
- Low
- Impact
- Data Tampering
- Component
- OS kernel
- Class
- Authorization Bypass
- Remediation
- Upgrade
- Effort
- Medium
- Patch risk
- Low
What it actually does
The NFSv2 SETACL handler in nfsd unconditionally passes potentially NULL acl_access and acl_default pointers from the decoded request to set_posix_acl, which treats a NULL pointer as a request to delete that ACL type; requests with only NFS_ACL or mask=0 therefore silently strip default ACLs or both ACLs.
Why it matters to the business
Remote attackers can remove file and directory access controls on any NFS-exported filesystem without authentication, resulting in unauthorized data access or privilege escalation across shared storage.
How an attack unfolds
An attacker sends a crafted NFSACL v2 SETACL request containing only the NFS_ACL mask bit (or mask=0) to an exposed nfsd listener; the server decodes the request with a NULL pointer for the omitted ACL, then calls set_posix_acl with that NULL value, causing the VFS to delete the corresponding on-disk POSIX ACL.
How to fix it
Apply the upstream kernel patch that gates each set_posix_acl call on the corresponding mask bit and initializes error to zero before the out_drop_lock path; rebuild and deploy the updated kernel on all NFS servers.
How to confirm the fix worked
Inspect nfsacld_proc_setacl to confirm both set_posix_acl invocations are now protected by an explicit check of the NFS_ACL or NFS_DFACL bit in argp->mask and that a zero-mask request returns success without altering ACLs.
Typical attack path
- Locate an NFS server exporting filesystems with POSIX ACLs
- Craft an NFSv2 SETACL request with partial or zero mask
- Send the request to the nfsd listener
- Observe successful removal of default or all ACLs on the target directory
How to detect it
Correlate NFS server logs for SETACL operations that succeed with mask values other than the full NFS_ACL|NFS_DFACL combination; monitor filesystem audit events for unexpected removal of default ACLs on directories served by nfsd.
What your security team should do
- Prioritize kernel updates on all systems running nfsd
- Restrict NFSv2 and NFSACL traffic to trusted clients via firewall or export options
- Enable and review audit logs for unexpected ACL modifications on NFS exports
- Consider disabling NFSv2 if NFSv3 or later is sufficient for the environment
The record
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: nfsaclsvc_decode_setaclargs() fills in argp->acl_access only when NFS_ACL is set in the request mask and argp->acl_default only when NFS_DFACL is set, leaving the other pointer NULL because the argument buffer is zeroed up to pc_argzero before decode. nfsacld_proc_setacl() then hands both pointers to set_posix_acl() unconditionally. set_posix_acl(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 NFS_ACL silently strips the directory's default ACL; mask=0 strips both. This is the same defect just fixed in nfsd3_proc_setacl(); apply the same remedy. Gate each set_posix_acl() 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 out_drop_lock path and the unconditional posix_acl_release() in nfsaclsvc_release_setacl() already tolerate the skipped arms.
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|