CVE-2026-72219 in Linux
Summary
by MITRE • 08/15/2026
In the Linux kernel, the following vulnerability has been resolved:
lockd: Plug nlm_file leak when nlm_do_fopen() fails
A client can repeatedly drive nlm_do_fopen() failures by presenting file handles that the underlying export rejects. After kzalloc_obj() succeeds in nlm_lookup_file(), the freshly allocated nlm_file is not yet inserted into nlm_files[]. The nlm_do_fopen() failure path jumps
to out_unlock, which releases nlm_file_mutex and returns without freeing the allocation, so each failure leaks one nlm_file.
Route the failure through out_free so kfree() runs before the function returns.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/15/2026
The vulnerability in question affects the Linux kernel's lockd subsystem, specifically within the Network Lock Manager implementation that handles NFS file locking operations. This issue represents a memory leak condition that occurs during the processing of NLM (Network Lock Manager) file operations, where the nlm_do_fopen() function fails to properly clean up allocated resources when encountering certain error conditions. The flaw exists in the nlm_lookup_file() function which allocates memory for nlm_file structures using kzalloc_obj() but fails to insert the newly allocated structure into the nlm_files[] hash table before nlm_do_fopen() is called.
The technical implementation flaw stems from improper error handling within the lockd subsystem's file management logic. When nlm_do_fopen() encounters an export rejection or other failure conditions, the function's error path executes a jump to the out_unlock label rather than the out_free label that would properly invoke kfree() on the allocated nlm_file structure. This design flaw creates a memory leak scenario where each failed file operation results in one unreclaimed nlm_file allocation that remains in memory indefinitely. The vulnerability is particularly concerning because it can be exploited through repeated client requests that intentionally present file handles rejected by the underlying export mechanism, allowing an attacker to systematically consume system memory over time.
The operational impact of this vulnerability extends beyond simple resource exhaustion as it represents a potential denial of service condition that can degrade system performance or cause complete system instability. The leak occurs in a high-frequency processing path within the lockd subsystem, meaning that repeated NFS file locking operations can quickly accumulate leaked memory structures. From a security perspective, this vulnerability aligns with CWE-401, which describes improper handling of memory allocation failures and resource leaks in software systems. The memory consumption pattern creates a predictable degradation that could be exploited by malicious actors to exhaust system resources and potentially cause service disruption.
The mitigations for this vulnerability involve modifying the error handling path within nlm_do_fopen() to ensure proper cleanup regardless of whether the function succeeds or fails. The fix requires routing failure conditions through the out_free label instead of out_unlock, ensuring that kfree() is called on the allocated nlm_file structure before the function returns. This change aligns with established security practices for resource management in kernel space code and follows ATT&CK technique T1499.004 for resource exhaustion attacks by preventing the accumulation of leaked memory structures. The solution represents a straightforward defensive programming fix that maintains the existing functional behavior while eliminating the memory leak through proper error path handling. This vulnerability demonstrates the importance of careful resource management in kernel subsystems and highlights how seemingly minor error handling flaws can lead to significant operational impacts.