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.