CVE-2026-89664
largeRemote memory leak in Linux kernel nfsd via malformed NFSv4 OPEN (DoS)
A memory leak in the Linux kernel's NFSv4 server (nfsd) means that POSIX ACL objects allocated while decoding an OPEN operation are never freed when the request short-circuits on a non-seqid-mutating error, or when the operation is encoded on the replay path. An unauthenticated remote attacker who can reach an NFSv4 service can trigger the leak by repeatedly sending malformed OPEN compounds that carry valid POSIX ACL createhow4 attributes. Each such request leaks kernel memory referenced by op_pacl/op_dpacl, so sustained requests can exhaust server memory and cause denial of service (availability-only impact, consistent with the CVSS 7.5 A:H vector). Any system running an unfixed kernel that exports NFSv4 via the in-kernel nfsd server is affected; no specific kernel version ranges were given in the advisory, and the fix adds nfsd4_open_release() as the .op_release handler for OP_OPEN and moves the release call to cover both normal and replay paths. There is no known public PoC and the CVE is not on the CISA KEV list, so exploitation status is none known.
What to do: Update to a kernel that includes the fix (the commit adding nfsd4_open_release() for OP_OPEN and the unified op_release call site); distros will ship it via their stable kernel backports. In the meantime, restrict TCP/2049 (and rpcbind on 111) to trusted networks or VPN, and monitor slab usage / posix_acl object counts on NFS-exporting servers for unexplained growth. Since this is unauthenticated, any NFSv4 export reachable by an attacker is a candidate for slow memory exhaustion, so auditing exposure of nfsd hosts is the priority.
| Linux kernel (nfsd / NFSv4 server) | — |
Order-of-magnitude estimate by the model from install counts, market share and public scan data it knows; verify before quoting.
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.
- Vector
- CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
In the news0 stories
No ingested article mentions this CVE yet.