Cloudanix VulnDB

CVE-2026-89671

Critical · 9.1

CVSS

9.1

EPSS

0.5%

Published

Sep 11, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A bug in the Linux NFS server lets remote users remove file permission lists they should not be able to touch.

Exploitation
Remote Unauthenticated
Attacker needs
None
Complexity
Low
Impact
Privilege Gain
Component
OS kernel
Class
Authorization Bypass
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

nfsd3_proc_setacl calls set_posix_acl unconditionally for ACL_TYPE_ACCESS and ACL_TYPE_DEFAULT using pointers that remain NULL when the corresponding mask bits are unset by the decoder, causing the VFS to treat NULL as an explicit request to remove those ACLs.

Why it matters to the business

Remote unauthenticated attackers can silently strip POSIX ACLs from files and directories exported via NFSv3, resulting in unintended loss of access controls and potential exposure or modification of data.

How an attack unfolds

An attacker connects to an NFSv3 server and issues a crafted SETACL request whose mask omits NFS_ACL, NFS_DFACL, or both bits; the server passes the still-NULL pointers to set_posix_acl, which removes the corresponding on-disk ACLs, and returns success.

How to fix it

Apply the upstream kernel patch that wraps each set_posix_acl call inside the matching mask-bit test and initializes error before inode_lock; rebuild and deploy the fixed kernel on all NFS servers.

How to confirm the fix worked

Confirm the presence of the mask-bit guard around both set_posix_acl invocations in nfsd3_proc_setacl and that a mask=0 request now returns nfs_ok without altering ACLs.

Typical attack path

  1. Locate an NFSv3 export accepting connections from the attacker's address
  2. Craft a SETACL RPC with mask set to 0 or only NFS_ACL
  3. Transmit the request; server interprets NULL pointers as delete operations
  4. Verify that target ACLs have been removed on subsequent GETACL or ls -l

How to detect it

Inspect NFS server logs or packet captures for SETACL requests carrying mask values of 0 or NFS_ACL-only; correlate with subsequent changes in directory default ACLs.

What your security team should do

  • Patch NFS servers with the corrected kernel as soon as available
  • Restrict NFSv3 ACL operations to trusted client networks via export options or firewalls
  • Enable NFS server logging of SETACL requests and alert on mask values that omit expected bits
  • Audit file systems for unexpected ACL removals after any untrusted NFS traffic

The record

In the Linux kernel, the following vulnerability has been resolved: nfsd: gate nfs3 setacl by argp->mask nfsd3_proc_setacl() calls set_posix_acl() unconditionally for both ACL_TYPE_ACCESS and ACL_TYPE_DEFAULT, passing argp->acl_access and argp->acl_default verbatim. The NFSv3 ACL decoder only populates those pointers when the corresponding mask bit is set: nfs3svc_decode_setaclargs() if (args->mask & NFS_ACL) decode into acl_access if (args->mask & NFS_DFACL) decode into acl_default /* otherwise the pointer stays NULL (pc_argzero) */ nfsd3_proc_setacl() set_posix_acl(.., ACL_TYPE_ACCESS, argp->acl_access) set_posix_acl(.., ACL_TYPE_DEFAULT, argp->acl_default) set_posix_acl(idmap, dentry, type, NULL) is the VFS "remove this ACL type" operation. A NULL pointer that means "the client did not send this arm" is therefore indistinguishable from "the client asked to remove this ACL". A SETACL with mask=NFS_ACL silently drops the directory's default ACL; mask=0 drops both. The sibling nfsd3_proc_getacl() already consults argp->mask before touching each arm; mirror that in setacl. Fix by wrapping each set_posix_acl() call in the matching mask bit check and initializing error to 0 before inode_lock so that a request with neither bit set leaves the on-disk ACLs untouched and returns nfs_ok. The out_drop_lock path and the unconditional posix_acl_release() at out: are preserved; both NULL-tolerate the skipped arms.

Affected packages

Ecosystem Package Introduced Fixed