Linux 5.14 · QEMU
Privilege escalation from an unprivileged process to a passwordless root login in the test VM.
💡 From the presentation, slide 3: crossing from kmalloc-128 to page-table pages through the buddy allocator
CacheMeIfYouCan is a reimplementation of SLUBStick on Linux 5.14. It uses a double free in the kernel heap to recycle a slab page as a page-table page, obtain physical memory access and gain root privileges. I built it with Leonardo Sinibaldi for the Advanced Operating Systems course at PoliMi.
We tested the exploit in a QEMU virtual machine, where an unprivileged user obtains a passwordless root login.
Source codeA double free or a constrained write may only affect objects within a particular kernel heap cache. Cross-cache exploitation uses page recycling to reach data allocated outside that cache.
Linux's SLUB allocator groups objects into caches. In our case, the vulnerable object lives in kmalloc-128, a general-purpose cache for small allocations. Page tables, which map virtual addresses to physical memory, are allocated separately.
When a slab becomes empty and its page returns to the buddy allocator, the page can be reused for a page table. A dangling reference into the original slab can then be used to modify the page table.
💡 From the presentation, slide 3: crossing from kmalloc-128 to page-table pages through the buddy allocator
The exploit uses four primitives: allocation timing, allocations to fill the target cache, a double free and a write that can be delayed until the page has been recycled.
Short-lived allocations through the key-management subsystem provide the timing measurements. The Distributed Lock Manager provides allocations in kmalloc-128. CVE-2022-2588, in the route4 traffic-control path, supplies the double free. The ALSA sound subsystem's replace_user_tlv() path supplies the write primitive.
We first implemented the mechanism in a custom kernel module so we could inspect the cache at each step. We then replaced the synthetic primitives with real kernel interfaces and the vulnerability.
📺 From the presentation, slide 4: the four kernel primitives used by the cross-cache attack
Allocation latency varies with the path taken: the CPU's freelist, a partial slab or a new page from the buddy allocator.
The timing side channel detects when SLUB obtains a fresh slab page. We use that feedback to track allocations while filling the cache with padding and vulnerable objects.
The timing technique comes from the original SLUBStick work. Our project adapts it to Linux 5.14 and the kernel interfaces available in our test environment.
📺 From the presentation, slide 6: allocation latency reveals when the allocator obtains a fresh slab
The write must complete after the slab page has been reclaimed as a page table. Relying on normal scheduling leaves a narrow window for this sequence.
We use FUSE to delay the write. When the kernel tries to copy data from a FUSE-backed userspace page, a page fault hands control to our filesystem process. That process waits for a signal before completing the request.
Three processes coordinate through pipes. Process B starts the write and blocks inside copy_from_user(). While FUSE holds the fault, process A releases the slab page and arranges for it to be reclaimed as a page-table page. A then signals FUSE to let B's pending write finish.
The pending write uses the dangling reference to modify memory that now belongs to the page table.
📺 From the presentation, slide 7: FUSE holds the page fault while process A recycles and reclaims the slab page
Corrupting the reclaimed page-table entry changes its physical frame address and huge-page flag. In our setup, this creates a 1 GB read/write window over physical memory.
To access memory beyond that window, we allocate 512 MB of userspace memory and put an identifiable marker in each 4 KB page. Finding those markers inside the window identifies the corresponding physical pages.
We locate a page-table entry mapping one of those pages and verify it by modifying the entry and observing the userspace mapping. Controlling a valid PTE lets us redirect the same virtual address to different physical frames, giving arbitrary physical memory read and write.
📺 From the presentation, slide 8: from page-table corruption to arbitrary physical memory access and root
For the demonstration, we bring /etc/passwd into the page cache, locate its contents in physical memory and change the root entry's password field. The login process then reads the modified cached contents.
In our QEMU environment, the Telnet login initially asks for the root password. After the exploit runs from the unprivileged account, the same login grants root access without a password.
We validated this on our configured Linux 5.14 VM. The exploit modifies the in-memory page cache. We did not test persistence on disk or measure success rates on other kernels and configurations.
📺 From the presentation, slide 9: the exploit output on the left and the successful root login on the right
Privilege escalation from an unprivileged process to a passwordless root login in the test VM.
The initial mapping obtained through page-table corruption, used to find and take control of a valid PTE.
Page recycling, the pending write and the FUSE fault handler, synchronized through pipes.
We used GDB and allocator inspection scripts to track page ownership and diagnose failed attempts and kernel crashes.
The repository includes GDB tools for walking SLUB freelists and page tables, a buddy-allocator inspection script and a breakpoint in the custom module. These let us follow a page as it leaves a slab and is reused.
It also includes a video of the exploit and setup and execution scripts for the kernel, modules, filesystem and QEMU environment.
I worked on page recycling, synchronization through pipes and the FUSE mechanism that extends the recycling window. I also worked on moving the primitives from our custom module to real kernel interfaces.
Leonardo worked on the timing side channel, the route4 vulnerability, the ALSA write trigger and the memory-write infrastructure used for the final /etc/passwd modification.
The code, setup scripts and demo are on GitHub 
. Implementation details and diagrams are in the project report and presentation slides.