CVE-2022-49927 in Linux
Summary
by MITRE • 05/01/2025
In the Linux kernel, the following vulnerability has been resolved:
nfs4: Fix kmemleak when allocate slot failed
If one of the slot allocate failed, should cleanup all the other allocated slots, otherwise, the allocated slots will leak:
unreferenced object 0xffff8881115aa100 (size 64): comm ""mount.nfs"", pid 679, jiffies 4294744957 (age 115.037s) hex dump (first 32 bytes): 00 cc 19 73 81 88 ff ff 00 a0 5a 11 81 88 ff ff ...s......Z..... 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [] nfs4_find_or_create_slot+0x8e/0x130
[] nfs4_realloc_slot_table+0x23f/0x270
[] nfs40_init_client+0x4a/0x90
[] nfs4_init_client+0xce/0x270
[] nfs4_set_client+0x1a2/0x2b0
[] nfs4_create_server+0x300/0x5f0
[] nfs4_try_get_tree+0x65/0x110
[] vfs_get_tree+0x41/0xf0
[] path_mount+0x9b3/0xdd0
[] __x64_sys_mount+0x190/0x1d0
[] do_syscall_64+0x35/0x80
[] entry_SYSCALL_64_after_hwframe+0x46/0xb0
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 03/15/2026
The vulnerability described in CVE-2022-49927 represents a memory management issue within the Linux kernel's Network File System version 4 implementation. This flaw manifests as a kmemleak condition that occurs during the allocation process of NFSv4 slots, which are essential components for managing concurrent operations between NFS clients and servers. The issue specifically affects the nfs4_realloc_slot_table function where slot allocation failures do not trigger proper cleanup of previously allocated resources, leading to memory leaks that persist until system reboot.
The technical root cause of this vulnerability lies in the improper resource management within the NFSv4 client implementation. When the system attempts to allocate slots for handling concurrent NFS operations and encounters a failure in allocating one of the slots, the kernel fails to properly release all previously allocated slots from the same allocation attempt. This creates a memory leak scenario where allocated kernel memory remains unreferenced and unavailable for reuse, gradually consuming system resources over time. The backtrace indicates the failure originates from nfs4_find_or_create_slot function and propagates through nfs4_realloc_slot_table, ultimately affecting the nfs40_init_client initialization process where the slot table reallocation occurs.
This vulnerability directly impacts system stability and resource utilization in environments heavily dependent on NFSv4 operations. The kmemleak condition can lead to progressive memory consumption that may eventually cause system performance degradation or even system crashes in resource-constrained environments. The leaked memory segments, each 64 bytes in size as indicated in the dump, accumulate over time and can significantly impact long-running systems or those with high NFS activity. The vulnerability affects processes such as mount.nfs which are critical for mounting NFS filesystems, making it particularly dangerous in enterprise environments where NFS is widely used for shared storage solutions.
From a security perspective, this vulnerability aligns with CWE-401: "Improper Release of Memory Before Removing Last Reference" and represents a denial-of-service risk that could be exploited by attackers to consume system resources over time. The vulnerability does not directly enable arbitrary code execution but creates conditions where system stability is compromised through resource exhaustion. It also relates to ATT&CK technique T1499.001: "Resource Hijacking: Network Denial of Service" as it can contribute to service disruption through memory exhaustion. The fix implemented addresses the resource management issue by ensuring that when slot allocation fails, all previously allocated slots within the same allocation attempt are properly cleaned up, preventing the accumulation of leaked memory segments.
The mitigation strategy for this vulnerability involves applying the kernel patch that corrects the slot allocation cleanup logic in the NFSv4 implementation. System administrators should prioritize updating their Linux kernel versions to include this fix, particularly in production environments where NFSv4 is extensively used. Monitoring for memory leaks and resource consumption patterns should be implemented to detect potential exploitation of this vulnerability. Organizations using NFSv4 services should also consider implementing automated patch management processes to ensure timely deployment of kernel security updates. The vulnerability demonstrates the importance of proper resource cleanup in kernel space operations and highlights the need for comprehensive testing of error paths in system components that manage shared resources.