CVE-2026-89664: nfsd: release OPEN-decoded posix ACLs via op_release

CVE-2026-89664: nfsd: release OPEN-decoded posix ACLs via op_release

[Greg Kroah-Hartman]

From: Greg Kroah-Hartman <gregkh@kernel.org>

Description
===========

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.

The Linux kernel CVE team has assigned CVE-2026-89664 to this issue.


Affected and fixed versions
===========================

	Issue introduced in 7.0 with commit 5fc51dfc2eb160bd7ab3251ab1767cacf9c8bf05 and fixed in 7.2.4 with commit 5b3a7d7c23c071efe12dd1bc1d2e5f97c4892921
	Issue introduced in 7.0 with commit 5fc51dfc2eb160bd7ab3251ab1767cacf9c8bf05 and fixed in 7.3-rc1 with commit 8215892993ea9f5231da4fa9eb42428a286fce8b

Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.

Unaffected versions might change over time as fixes are backported to
older supported kernel versions.  The official CVE entry at
	https://cve.org/CVERecord/?id=CVE-2026-89664
will be updated if fixes are backported, please check that for the most
up to date information about this issue.


Affected files
==============

The file(s) affected by this issue are:
	fs/nfsd/nfs4proc.c
	fs/nfsd/nfs4xdr.c


Mitigation
==========

The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes.  Individual
changes are never tested alone, but rather are part of a larger kernel
release.  Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all.  If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
	https://git.kernel.org/stable/c/5b3a7d7c23c071efe12dd1bc1d2e5f97c4892921
	https://git.kernel.org/stable/c/8215892993ea9f5231da4fa9eb42428a286fce8b