CVE-2026-72218 in Linux
Summary
by MITRE • 08/15/2026
In the Linux kernel, the following vulnerability has been resolved:
lockd: Plug nlm_file refcount leak on cached nlm_do_fopen() failure
The cached-file path in nlm_lookup_file() reaches the found: label unconditionally, even when nlm_do_fopen() fails. At that label *result and file->f_count are updated before the error is returned. The wrappers nlm3svc_lookup_file() and nlm4svc_lookup_file() then bail out of their switch without copying *result back to their caller, so the proc handler's local nlm_file pointer remains NULL and the cleanup path skips nlm_release_file(). The f_count increment is never released, and nlm_traverse_files() can no longer reap the file because its refcount never returns to zero between requests.
Short-circuit the cached path so neither *result nor f_count is touched when nlm_do_fopen() fails on a hashed nlm_file.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/15/2026
The vulnerability described represents a critical reference counting flaw within the Linux kernel's lockd subsystem, specifically affecting Network Lock Manager operations in NFS implementations. This issue resides in the nlm_lookup_file function where the cached file path executes without proper error handling mechanisms, creating a resource leak scenario that can persist across multiple system operations. The flaw manifests when nlm_do_fopen() encounters a failure condition during file access validation, yet the code continues execution toward the found: label regardless of this failure state.
The technical implementation defect stems from improper control flow management within the lockd service handling logic where the reference count increment occurs before error propagation. When nlm_do_fopen() fails on a cached nlm_file object, the system updates result and file->f_count variables before returning the error condition to higher-level callers. This sequence creates a scenario where the nlm3svc_lookup_file() and nlm4svc_lookup_file() wrapper functions exit their switch statements without properly synchronizing the result value back to the calling context. The consequence is that local nlm_file pointers remain NULL in the procedure handlers, causing subsequent cleanup routines to skip the critical nlm_release_file() function call.
This vulnerability directly maps to CWE-401 Memory Leak and aligns with ATT&CK technique T1486 Data Encrypted for Impact, as it represents a persistent resource consumption issue that can degrade system performance over time. The failure to properly manage reference counts creates a condition where file descriptors remain in an inconsistent state, preventing proper garbage collection by nlm_traverse_files() routine. This memory management defect allows for gradual accumulation of unreleased file references, effectively creating a denial-of-service vector that can impact NFS service availability.
The operational impact extends beyond simple resource leakage to potentially compromise system stability and performance under sustained load conditions. Attackers could exploit this vulnerability by repeatedly triggering the cached file lookup path with invalid parameters, causing progressive accumulation of file reference counts that never decrement properly. The mitigation strategy requires implementing early exit conditions in the cached file path logic, specifically preventing updates to *result and file->f_count variables when nlm_do_fopen() fails on hashed nlm_file objects. This approach ensures proper error propagation and maintains consistent reference counting semantics across all code paths.
Security practitioners should consider this vulnerability as part of broader NFS security assessments and implement monitoring for unusual file descriptor accumulation patterns in lockd processes. The fix involves modifying the conditional logic to short-circuit the cached path when nlm_do_fopen() fails, ensuring that neither *result nor f_count is modified during error conditions while maintaining proper cleanup procedures for valid operations. This remediation aligns with secure coding practices recommended in NIST SP 800-160 and follows the principle of least privilege by preventing unauthorized resource consumption through improper reference counting management in kernel space operations.