CVE-2024-56779 in Linux
Summary
by MITRE • 01/08/2025
In the Linux kernel, the following vulnerability has been resolved:
nfsd: fix nfs4_openowner leak when concurrent nfsd4_open occur
The action force umount(umount -f) will attempt to kill all rpc_task even umount operation may ultimately fail if some files remain open. Consequently, if an action attempts to open a file, it can potentially send two rpc_task to nfs server.
NFS CLIENT thread1 thread2 open("file") ... nfs4_do_open _nfs4_do_open _nfs4_open_and_get_state _nfs4_proc_open nfs4_run_open_task /* rpc_task1 */ rpc_run_task rpc_wait_for_completion_task
umount -f nfs_umount_begin rpc_killall_tasks rpc_signal_task rpc_task1 been wakeup and return -512 _nfs4_do_open // while loop ... nfs4_run_open_task /* rpc_task2 */ rpc_run_task rpc_wait_for_completion_task
While processing an open request, nfsd will first attempt to find or allocate an nfs4_openowner. If it finds an nfs4_openowner that is not marked as NFS4_OO_CONFIRMED, this nfs4_openowner will released. Since two rpc_task can attempt to open the same file simultaneously from the client to server, and because two instances of nfsd can run concurrently, this situation can lead to lots of memory leak. Additionally, when we echo 0 to /proc/fs/nfsd/threads, warning will be triggered.
NFS SERVER nfsd1 nfsd2 echo 0 > /proc/fs/nfsd/threads
nfsd4_open nfsd4_process_open1 find_or_alloc_open_stateowner // alloc oo1, stateid1 nfsd4_open nfsd4_process_open1 find_or_alloc_open_stateowner // find oo1, without NFS4_OO_CONFIRMED release_openowner unhash_openowner_locked list_del_init(&oo->oo_perclient) // cannot find this oo // from client, LEAK!!! alloc_stateowner // alloc oo2
nfsd4_process_open2 init_open_stateid // associate oo1 // with stateid1, stateid1 LEAK!!! nfs4_get_vfs_file // alloc nfsd_file1 and nfsd_file_mark1 // all LEAK!!!
nfsd4_process_open2 ...
write_threads ... nfsd_destroy_serv nfsd_shutdown_net nfs4_state_shutdown_net nfs4_state_destroy_net destroy_client __destroy_client // won't find oo1!!! nfsd_shutdown_generic nfsd_file_cache_shutdown kmem_cache_destroy for nfsd_file_slab and nfsd_file_mark_slab // bark since nfsd_file1 // and nfsd_file_mark1 // still alive
======================================================================= BUG nfsd_file (Not tainted): Objects remaining in nfsd_file on __kmem_cache_shutdown() -----------------------------------------------------------------------
Slab 0xffd4000004438a80 objects=34 used=1 fp=0xff11000110e2ad28 flags=0x17ffffc0000240(workingset|head|node=0|zone=2|lastcpupid=0x1fffff) CPU: 4 UID: 0 PID: 757 Comm: sh Not tainted 6.12.0-rc6+ #19 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 Call Trace: dum ---truncated---
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 11/24/2025
The vulnerability identified as CVE-2024-56779 resides within the Linux kernel's Network File System version 4 implementation, specifically affecting the nfsd component responsible for handling NFS server operations. This flaw manifests as a memory leak occurring during concurrent nfsd4_open operations, where the improper handling of nfs4_openowner structures leads to resource exhaustion and potential system instability. The root cause lies in the failure to correctly manage state owner references when multiple simultaneous open requests are processed, particularly under conditions involving forced unmount operations.
The technical mechanism of this vulnerability involves a race condition between client-side file opening operations and server-side cleanup processes during forced unmounts. When an umount -f command is executed, it attempts to terminate all rpc_task processes associated with the NFS mount, which can result in interrupted open operations. Concurrent threads attempting to open the same file simultaneously can generate two rpc_task instances that both interact with the same nfs4_openowner structure. The first task may be interrupted by the unmount process, returning an error code -512, while a second task continues to execute, creating a scenario where the openowner reference is not properly managed.
According to CWE-401, this vulnerability represents a classic memory leak issue where allocated resources are not correctly released, leading to gradual memory consumption. The flaw operates through a complex interaction between multiple kernel subsystems including the NFS server implementation, RPC task management, and memory allocation mechanisms. The concurrent execution paths of nfsd threads exacerbate the problem, as the state owner management code path does not properly account for the possibility that an openowner may be freed and reallocated while another thread is still processing related operations.
The operational impact of this vulnerability is significant, particularly in environments where high concurrent access to NFS shares occurs. Memory leaks accumulate over time, potentially leading to system performance degradation, resource exhaustion, and eventually system instability or crashes. The warning messages triggered when writing to /proc/fs/nfsd/threads indicate that the kernel's internal state management has detected unreleased resources, which can be particularly problematic in production environments where sustained NFS operations are expected. The vulnerability affects the kernel's ability to properly clean up memory allocations during shutdown sequences, as evidenced by the kmem_cache_destroy warnings that occur when attempting to destroy the nfsd file cache.
Mitigation strategies for this vulnerability should focus on implementing proper synchronization mechanisms to prevent race conditions during openowner allocation and deallocation. The recommended approach involves enhancing the nfsd4_open processing logic to ensure that state owner references are properly tracked and released, even when concurrent operations occur. System administrators should monitor memory usage patterns on NFS servers and consider implementing periodic restarts of NFS services to prevent memory leaks from accumulating. Additionally, kernel updates containing the specific fix for this vulnerability should be applied immediately, as the memory leak can compound over time and potentially lead to system resource exhaustion. The ATT&CK framework's T1499.004 technique for "Resource Hijacking" is relevant here, as the memory leak effectively hijacks system resources that should be available for legitimate operations, potentially enabling denial of service conditions.