CVE-2026-89664
Summary
by MITRE • 09/11/2026
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.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/11/2026
The Linux kernel NFS server daemon contains a resource management vulnerability within the handling of OPEN compound operations that results in memory leaks through unreleased reference counts on POSIX Access Control List objects. This flaw originates from an inconsistency in how resources are allocated during the decoding phase versus when they are released after processing completes. Specifically, the function nfsd4_decode_createhow4 invokes nfsd4_decode_fattr4 to process file attributes, which subsequently allocates refcounted struct posix_acl objects via posix_acl_alloc and stores them within the open operation structure at op_pacl and op_dpacl fields. These allocated resources represent kernel memory that must be explicitly freed once the OPEN compound processing concludes to prevent accumulation of unused allocations over time.
The vulnerability manifests primarily when nfsd4_decode_open_claim4 returns a non-seqid-mutating error, triggering an early exit path in the request dispatcher before the main operation function is executed. In this scenario, the code short-circuits and returns the status immediately without invoking the core open processing logic that would normally handle cleanup. Prior to the fix, the OP_OPEN descriptor lacked a dedicated op_release callback within the nfsd4_ops array structure. Instead, resource release was hardcoded inside the nfsd4_open function at its error handling label. Because this short-circuit path bypasses nfsd4_open entirely, both posix_acl references remain allocated and unreleased on every malformed OPEN compound that carries valid POSIX ACL createhow attributes. This constitutes a classic use-after-free or memory leak pattern where resources are acquired but not returned to the system under specific error conditions.
Furthermore, the vulnerability extends beyond simple short-circuit paths due to structural issues in how operation release callbacks were invoked across different execution branches of the compound loop. The NFSv4 protocol processing includes two distinct encoding pathways: nfsd4_encode_operation for standard operations and nfsd4_encode_replay for replayed operations in version 4.0 sessions. Previously, op_release was only called from within nfsd4_encode_operation, meaning that resources attached to op->u leaked on the replay path where this function is not invoked. This inconsistency created multiple vectors for resource leakage depending on whether a request was processed normally or as part of a session replay mechanism.
The remediation involves implementing a dedicated release callback named nfsd4_open_release and wiring it as the .op_release handler for OP_OPEN in the operation descriptor table. Since posix_acl_release is designed to be NULL-safe, this single release site effectively covers both the normal execution path and the short-circuit error path without requiring conditional checks. To prevent double-releasing of resources, the matching posix_acl_release calls previously embedded within nfsd4_open's out_err label are removed. This consolidation ensures that all code paths leading from an OPEN operation result in exactly one release call per allocated ACL object.
Additionally, the fix addresses the replay path leakage by restructuring when op_release is invoked relative to encoding functions. The op_release call is moved out of nfsd4_encode_operation and its associated replay branch, placing it after the conditional logic block within nfsd4_proc_compound. This architectural change establishes a single, centralized call site that executes regardless of whether normal or replayed operation encoding occurs. By decoupling resource release from specific encoding functions, the kernel ensures consistent cleanup behavior across all operational modes including standard requests and session replays.
From a security taxonomy perspective, this vulnerability aligns with CWE-401 which describes missing release of memory after effective lifetime leading to information leakage or denial of service through resource exhaustion. In terms of adversarial tactics, while not directly exploitable for remote code execution in its current form, persistent memory leaks can contribute to system instability and potential denial-of-service conditions over extended periods as the kernel's memory footprint grows uncontrollably under high load with malformed requests. The fix demonstrates proper adherence to defensive programming principles by ensuring symmetric allocation and deallocation patterns across all control flow paths within complex protocol handling code.