CVE-2025-21866 - KASAN Out-of-Bounds Write in Linux PowerPC Kernel Text Patching

On certain PowerPC systems running KASAN (Kernel Address SANitizer) enabled Linux kernels, a bug allowed uninitialized virtual memory to be written to inside the kernel during code patching operations. CVE-2025-21866 captures this quietly impactful vulnerability, which was ultimately patched in kernel version 6.13-rc6. This post walks you through what happened, why it matters, how it was fixed, and gives explained code examples to help you understand the root cause.

What Happened?

A user named Erhard reported that when he tried booting a PowerMac G4 with KASAN enabled in the kernel, the system ran into a KASAN out-of-bounds write bug:

BUG: KASAN: vmalloc-out-of-bounds in copy_to_kernel_nofault+xd8/x1c8
Write of size 8 at addr f100000 by task chronyd/1293
...
The buggy address belongs to the virtual mapping at
 f100000, f100200) created by: text_area_cpu_up+x20/x190

Technical summary:
The kernel’s PowerPC text patching code used an internal memory area created with get_vm_area() and flagged it wrongly as VM_ALLOC. But memory with that flag isn’t ready to use until additional initialization happens (specifically, after a function called __vmalloc_node_range()), which didn’t occur in this case.

With recent changes, Linux’s memory checks (KASAN) started catching this error. It found that the area was still "poisoned" (full of marker value xf8 = KASAN_VMALLOC_INVALID), meaning no code should write here yet. But the kernel went ahead and wrote to it—a major violation in memory-safe programming.Can crash or corrupt the system during boot or runtime.- Creates possible attack surface, since writing to uninitialized memory areas can sometimes be exploited (e.g., info leaks, privilege escalation in other contexts).
Here’s a simplified version of what went wrong in pseudo C codeThe area was _marked as_ VM_ALLOC, but never given real memory by __vmalloc_node_range(), so KASAN flagged any accesses as bugs.
The FixSolution:
Simply stop telling the kernel this area is "vmalloc-allocated" by dropping the VM_ALLOC flag.Corrected CodeThis way, the memory region is recognized as a plain mapping, not subject to vmalloc tracking, and is not poisoned by KASAN anymore—so it can be safely written immediately after allocation.Link to Upstream Fix

Original commit:
[powerpc/code-patching: Fix KASAN hit by not flagging text patching area as VM_ALLOC

Discussion threads:
- LKML Patch Discussion
- Bugzilla Report

PowerPC systems using text patching for BPF JIT, livepatch, or kernel probes

- Only when KASAN is enabled (default for kernel debugging, not production, but important for kernel developers)

Is There a Working Exploit?

There’s no public exploit targeting this bug directly. However, out-of-bounds kernel memory writes always represent an escalation risk. If attackers could either control the patching code or its memory targets, they *might* be able to escalate privileges or crash the machine by exploiting this latent vulnerability—hence why it was assigned a CVE.

Here’s a simplified dummy code demonstrating the risky pattern (hypothetical for education)

#define SIZE 4096

void buggy_allocation_example(void) {
    struct vm_struct *area = get_vm_area(SIZE, VM_ALLOC);
    if (!area) {
        pr_err("Failed to allocate patch area!\n");
        return;
    }
    // Direct write - BAD! This memory is KASAN poisoned
    ((u64*)area->addr)[] = xdeadbeef;
}

In KASAN-enabled kernels, this would hit a "out-of-bounds write" warning referencing the "f8 f8 f8 f8" pattern, just like the report.

How Do You Mitigate?

- Upgrade to a kernel including/after the referenced patch (6.13-rc6 or later).
- If backporting, ensure your patch for arch/powerpc/kernel/code-patching.c matches the upstream fix.

Additional References

- KASAN Documentation
- Linux kernel commit browser
- VMALLOC flags usage

Conclusion

CVE-2025-21866 is a developer-facing bug, but serves as a good reminder:
Kernel memory flags are more than just numbers—they carry *meaning* that the memory debugging (KASAN) infrastructure depends on. A single misplaced flag can poison a memory region and cause hard-to-find bugs.

If you maintain PowerPC Linux systems or custom kernel patches, double-check how you allocate and use any VM areas, and always verify how changes interact with tools like KASAN.

Stay patched, and keep your kernels tidy!

*Author: [Your Name], 2024*
*If you have further questions or need CVE remediation advice, leave a comment or visit the linked bug discussion pages.*

Timeline

Published on: 03/12/2025 10:15:19 UTC
Last modified on: 03/24/2025 15:41:37 UTC