CVE-2024-36288

What it actually does

Missing NULL termination on the in_token->pages[] array in gss_free_in_token_pages() allows the loop to read past the end of the array, resulting in wild memory access and KASAN detection of out-of-bounds reads in the Linux kernel SUNRPC GSS handling path.

Why it matters to the business

Linux systems handling RPC with GSS authentication can experience kernel crashes or denial of service, disrupting services that rely on NFS, Kerberos, or other SUNRPC-based protocols until the kernel is updated.

How an attack unfolds

An attacker with local access crafts or triggers a GSS token whose pages array lacks proper termination; the kernel's free routine then iterates beyond the allocated pages, triggering memory corruption that may be used for denial of service.

How to fix it

Update the Linux kernel to a version containing commit 57ff6c0a175930856213b2aa39f8c845a53e5b1c or later; rebuild and reboot with the patched kernel. Where live patching is available, apply the vendor's live patch for this fix.

How to confirm the fix worked

Verify the running kernel contains commit 57ff6c0a175930856213b2aa39f8c845a53e5b1c via 'git log' or package version; confirm absence of the KASAN splat 'maybe wild-memory-access in range [0x04a2013400000008-0x04a201340000000f]' under GSS token workloads.

Typical attack path

1. Obtain local code execution or user-level access on a Linux host
2. Trigger SUNRPC GSS authentication path that allocates an in_token structure
3. Supply a token whose pages array is not NULL-terminated
4. Invoke gss_free_in_token_pages() which walks the array without a termination check
5. Cause out-of-bounds memory read leading to KASAN fault or kernel panic

How to detect it

Search kernel logs and dmesg for the exact KASAN message mentioning wild-memory-access and gss_free_in_token_pages; inspect audit logs for unusual local processes triggering SUNRPC GSS operations around crash times.

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

What your security team should do

• Apply the kernel update containing commit 57ff6c0a175930856213b2aa39f8c845a53e5b1c within the next patching cycle
• Monitor kernel logs for KASAN reports referencing gss_free_in_token_pages
• Restrict local user access on systems that expose SUNRPC/GSS until patched