In May 2024, a vulnerability was identified in the Linux kernel affecting the Network File System daemon (nfsd), specifically when handling NFSv4. open files. Labeled as CVE-2024-46682, this bug could lead to a kernel panic (oops), posing denial-of-service risks for Linux NFS servers. In this article, we’ll break down the vulnerability, show how it can be triggered, offer sample exploit steps, and point to the fix—using simple language for easy understanding.
What is CVE-2024-46682?
CVE-2024-46682 is a bug in the way the Linux kernel’s NFS daemon (nfsd) exposes information for NFSv4. open files through the /proc filesystem. After a file is closed, the server’s internal state tracking could leave some variables unset. When userspace tools (like cat) access /proc/fs/nfsd/clients/<client>/states, the kernel tried to dereference a NULL pointer, leading to a kernel oops (panic).
Let’s focus on the key code
// Before the fix
sc_type = ; // Used to signal uninitialized (invalid) state to other functions
// After commit 3f29cc82a84c, sc_type is no longer zeroed:
// Instead, sc_status tracks validity, but sc_type stays non-zero
// In nfs4_show_open()
if (state->sc_file) {
// Access file-specific details
} else {
// Before the FIX: Code still tried to access sc_file (which is NULL!)
// This would trigger a NULL pointer dereference (oops)
}
The bug was introduced in commit 3f29cc82a84c. This commit split state validity from sc_type into a new sc_status field. But some code paths still assumed the presence of a valid sc_file, leading to an oops when it was missing.
`bash
mount -t nfs -o vers=4.:/exported /mnt
`bash
cat /mnt/somefile > /dev/null
`bash
cat /proc/fs/nfsd/clients/*/states
[ 513.590804] Call trace
[ 513.590925] _raw_spin_lock+xcc/x160
[ 513.591119] nfs4_show_open+x78/x2c [nfsd]
[ 513.591412] states_show+x44c/x488 [nfsd]
[ 513.591681] seq_read_iter+x5d8/x760
[ 513.591896] seq_read+x188/x208
[ 513.592075] vfs_read+x148/x470
[ 513.592241] ksys_read+xcc/x178
`
Impact:
Any unprivileged user able to mount and access the NFS share could potentially trigger the kernel crash, leading to a denial of service.
The Fix (Commit Explanation)
The fix is simple:
> If the sc_file in the state is NULL (meaning the file’s been closed), the reporting function skips displaying file-specific information, which avoids the NULL dereference.
Here’s roughly what changed, in C code
int nfs4_show_open(struct seq_file *m, struct nfs4_state *state)
{
if (!state->sc_file) {
// Don't access sc_file - skip this or print minimal info
return ;
}
// Safe: proceed to show open state info
}
Official Commit
- Linux commit a2013c03b311419e2ea4e37ea9e4960047473153
References
- Linux Kernel Commit: split sc_status out of sc_type
- Patch Fixing CVE-2024-46682
- Red Hat Bugzilla: 2283149
- kernel.org NFS commits
Conclusion
CVE-2024-46682 demonstrates how subtle changes in internal kernel tracking can result in serious (but unintentional) denial-of-service vulnerabilities. All Linux hosts exposing NFS should patch their systems if they’re running affected kernel versions.
Mitigation:
- Update your kernel to include the fix from a2013c03b311
Timeline
Published on: 09/13/2024 06:15:12 UTC
Last modified on: 09/15/2024 17:57:33 UTC