CVE-2026-89664

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

nfsd: release OPEN-decoded posix ACLs via op release

nfsd4 decode createhow4() calls nfsd4 decode fattr4(), which allocates refcounted struct posix acl objects via posix acl alloc() and stores them in open->op pacl and open->op dpacl. These pointers must be released once the OPEN compound finishes.

When nfsd4 decode open claim4() returns a non-seqid-mutating error, the dispatcher short-circuits before op func runs:

nfsd4 proc compound() if (op->status && op->opnum == OP OPEN) op->status = nfsd4 open omfg(...) if (!seqid mutating err(ntohl(op->status))) return op->status; /* nfsd4 open() never runs / ... opdesc->op release(&op->u) / must still release op pacl/op dpacl */

Before this change OP OPEN had no .op release in nfsd4 ops[], and the release pair lived inside nfsd4 open() at its out err: label. On the short-circuit path nfsd4 open() is never invoked, so both posix acl refs leak on every malformed OPEN compound that carries valid POSIX ACL createhow4 attributes.

Add nfsd4 open release() and wire it as .op release for OP OPEN. posix acl release() is NULL-safe, so the single release site covers both the normal path and the nfsd4 open omfg short-circuit. Remove the matching posix acl release() pair from nfsd4 open()'s out err: label to avoid double-releasing.

The compound loop has two encoding branches: nfsd4 encode operation() for normal ops, and nfsd4 encode replay() for v4.0 replayed ops. op release was only called from nfsd4 encode operation(), so resources attached to op->u leak on the replay path.

Move the op release() call out of nfsd4 encode operation() and the replay branch, placing it after the if-else in nfsd4 proc compound(). This gives a single call site in a fairly obviously-correct place, covering both the normal encoding and replay paths.