CVE-2024-36288 - Fixing SUNRPC Memory Access in Linux Kernel ([gss_free_in_token_pages()](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=36f57b6c741e109e664375f2bb002d4ccec42882) Danger)

A serious vulnerability, CVE-2024-36288, was found and quickly patched in the Linux kernel’s SUNRPC subsystem, specifically in the way it handles freeing certain memory pages for RPC security (GSS authentication). This issue could lead to out-of-bounds or wild memory access, detected via KASAN (Kernel Address Sanitizer), and had the potential to crash or destabilize the system.

In this post, we’ll break down the bug, show you the vulnerable code, explain what went wrong, explore proof-of-concept exploitation details, and link you to the mainline kernel fix.

What Is SUNRPC and GSS in the Linux Kernel?

- SUNRPC stands for Sun Remote Procedure Call, a protocol enabling communication between networked services or components.
- GSS (Generic Security Services) is used for secure authentication in remote services (often NFS).

Within these systems, careful memory management is critical, especially regarding allocated and freed memory.

What Happened?

The function gss_free_in_token_pages() is supposed to free a series of memory pages (pointers) stored inside the structure’s pages[] array. The security issue? The function incorrectly expects the pages[] array to be NULL-terminated, similar to how a C-string ends with \. But pages[] is not NULL-terminated! Instead, the only correct indicator of its length is a separate count field that records how many elements it holds.

Here’s the error you might see if the bug gets triggered

KASAN: maybe wild-memory-access in range [x04a2013400000008-x04a201340000000f]

KASAN stands for Kernel Address SANitizer, a tool that detects memory bugs at runtime.

- This means the kernel tried to access memory that wasn’t really part of the pages[] array, potentially leading to kernel crashes or undefined Linux kernel behavior.

Let’s see what the buggy function looked like (simplified)

// Vulnerable version (before the fix)
void gss_free_in_token_pages(struct in_token *in_token) {
    struct page **pages = in_token->pages;
    int i = ;

    // LOOPS until it finds a NULL, but array isn't NULL-terminated!
    while (pages[i]) {
        __free_page(pages[i]);
        i++;
    }
}

Problem: If there’s no NULL at the end, pages[i] goes out of bounds!

#### Patch/Fix

The correct way is to use the array size (here, pages_count)

// Fixed version
void gss_free_in_token_pages(struct in_token *in_token) {
    struct page **pages = in_token->pages;
    int count = in_token->pages_count;

    for (int i = ; i < count; i++)
        __free_page(pages[i]);
}

How Could This Be Exploited?

If an attacker can trigger a SUNRPC GSS-authenticated operation using a token with carefully crafted pages_count and page pointers, the kernel may:

Denial of service (DoS)

Remote exploitation would be hard without further vulnerabilities, but a local user or service with privileges could potentially crash the system.

Simple Proof-of-Concept

Note: Most users or admins won’t be able to exploit directly without custom kernel module or possessing root capabilities.

1. Make a struct in_token with more pages_count than actual entries or without ensuring array alignment.

Who’s Affected?

- All Linux kernel versions before the fix: commit 36f57b6c741e109e664375f2bb002d4ccec42882

Mainstream Linux distributions that enabled CONFIG_SUNRPC_GSS and didn’t backport the patch.

- NFS installations (especially with Kerberos/GSS security).

Official References

- Upstream kernel commit/fix
- syzkaller KASAN report on lore.kernel.org
- Openwall LKML CVE tracker

Upgrade to a kernel version after June 6, 2024

- For maintainers: backport patch 36f57b6c741e

Summary

CVE-2024-36288 demonstrates how a single mistaken assumption about array structure can lead to serious kernel vulnerabilities. If you run a server or distro that uses SUNRPC and GSS/krb5 (common for secure NFS!), check for this patch and update as soon as possible. Even though direct exploitation is tricky, the stability of your system may depend on it.

Stay Secure!

- Always monitor kernel advisories (OSS Security List)

Timeline

Published on: 06/21/2024 12:15:10 UTC
Last modified on: 06/27/2024 13:15:59 UTC