CVE-2024-56779: nfsd: fix nfs4_openowner leak when concurrent nfsd4_open occur
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:
<TASK>
dum
---truncated---
Security readout for executives and security teams
Plain-English summary
A Linux NFS server can leak kernel memory when concurrent file-open requests race during a forced client unmount. Repetition may consume resources and disrupt service. The supplied record rates it critical, although its technical description demonstrates memory leakage and shutdown warnings, not confirmed data theft or modification.
Executive priority
Treat remediation as urgent for exposed or business-critical NFS servers because repeated leakage could impair availability. Prioritize by NFS service exposure and operational importance. Systems not serving NFS are unlikely to encounter the described path. Do not infer confirmed confidentiality or integrity compromise solely from the supplied 9.8 score.
Technical view
CVE-2024-56779 is a CWE-401 resource leak in Linux nfsd. Concurrent NFSv4 OPEN processing can release an unconfirmed open owner while another request still associates state and file objects with it. Those objects become unreachable during cleanup, causing leaks and slab-cache warnings. Stable-kernel commits are supplied as fixes.
Likely exposure
Exposure is limited to systems running affected Linux kernels as NFS servers, particularly where concurrent NFSv4 opens and forced client unmounts occur. The bundled version data is insufficiently structured for reliable branch-by-branch conclusions; confirm applicability through the kernel or distribution advisory for each deployed build.
Exploitation context
The bundle does not establish active exploitation, and the CVE is not identified as KEV. It describes a concurrency-triggered server-side memory leak involving client opens and forced unmount behavior. Network reachability may enable triggering, but attacker control, reproducibility, and impact beyond resource exhaustion are not demonstrated here.
Researcher notes
The record’s CVSS 9.8 vector claims high confidentiality, integrity, and availability impact, while the supplied technical evidence directly supports a memory leak and cleanup warnings. No public exploitation evidence is included. Researchers should distinguish the demonstrated availability risk from unsubstantiated data compromise and verify exact affected ranges against stable-tree or distribution metadata.
Mitigation direction
Install a distribution kernel containing the applicable referenced stable-kernel fix.
Prioritize internet-accessible or broadly reachable NFS servers for remediation.
Restrict NFS access to required, trusted clients using existing network controls.
Minimize forced unmounts during active NFS operations until patched, where operationally feasible.
Check vendor guidance before applying branch-specific kernel changes.
Validation and detection
Inventory Linux systems currently providing NFS exports and record their running kernels.
Map each kernel build to its distribution advisory or applicable stable fix commit.
Confirm the corrected kernel is active after installation and reboot.
Review kernel logs for nfsd shutdown warnings or remaining nfsd_file objects.
Regression-test concurrent NFSv4 opens and service shutdown in an isolated environment.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cwe · low confidence lookup
CWE-401: Exact CWE lookup
Use the exact CWE identifier as the starting point before reviewing related ATT&CK behavior. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.
CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.
CWE-401 · source CWE mapping
Missing Release of Memory after Effective Lifetime
Missing Release of Memory after Effective Lifetime represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.