CVE-2026-89664: nfsd: release OPEN-decoded posix ACLs via op_release
In the Linux kernel, the following vulnerability has been resolved:
nfsd: release OPEN-decoded posix ACLs via oprelease
nfsd4decodecreatehow4() calls nfsd4decodefattr4(), which allocates refcounted struct posixacl objects via posixaclalloc() and stores them in open->oppacl and open->opdpacl. These pointers must be released once the OPEN compound finishes.
When nfsd4decodeopenclaim4() returns a non-seqid-mutating error, the dispatcher short-circuits before opfunc runs:
nfsd4proccompound() if (op->status && op->opnum == OPOPEN) op->status = nfsd4openomfg(...) if (!seqidmutatingerr(ntohl(op->status))) return op->status; / nfsd4open() never runs / ... opdesc->oprelease(&op->u) / must still release oppacl/opdpacl /
Before this change OPOPEN had no .oprelease in nfsd4ops[], and the release pair lived inside nfsd4open() at its outerr: label. On the short-circuit path nfsd4open() is never invoked, so both posixacl refs leak on every malformed OPEN compound that carries valid POSIX ACL createhow4 attributes.
Add nfsd4openrelease() and wire it as .oprelease for OPOPEN. posixaclrelease() is NULL-safe, so the single release site covers both the normal path and the nfsd4openomfg short-circuit. Remove the matching posixaclrelease() pair from nfsd4open()'s outerr: label to avoid double-releasing.
The compound loop has two encoding branches: nfsd4encodeoperation() for normal ops, and nfsd4encodereplay() for v4.0 replayed ops. oprelease was only called from nfsd4encodeoperation(), so resources attached to op->u leak on the replay path.
Move the oprelease() call out of nfsd4encodeoperation() and the replay branch, placing it after the if-else in nfsd4proccompound(). This gives a single call site in a fairly obviously-correct place, covering both the normal encoding and replay paths.
Affected Software
Event History
Frequently Asked Questions
What does an attacker need to send to trigger the leak?
The request must be a malformed NFSv4 OPEN compound carrying valid POSIX ACL createhow4 attributes. It must cause nfsd4_decode_open_claim4() to return a non-seqid-mutating error, which short-circuits processing before nfsd4_open() runs.
What is the practical effect of repeated triggering?
Each qualifying malformed OPEN compound leaks references to both ACL objects stored in op_pacl and op_dpacl. Repeated requests can therefore accumulate unreleased POSIX ACL references on the affected nfsd server.
How is the issue fixed?
The fix adds nfsd4_open_release() as the OP_OPEN operation release handler, ensuring the ACL pointers are released even on the short-circuit path. The provided stable commits are 5b3a7d7c23c071efe12dd1bc1d2e5f97c4892921 and 8215892993ea9f5231da4fa9eb42428a286fce8b.