IonStack part II: GhostLock, a stack-UAF that has existed in ALL Linux distributions for 15 years

Research IonStack part II: GhostLock, a stack-UAF that has existed in ALL Linux distributions for 15 years

GhostLock (CVE-2026-43499) is a Linux kernel vulnerability found by VEGA that exists in every major distribution since 2011. Triggering the bug does not require any special kernel config or privilege. By turning it into a 97% stable privilege escalation and container escape, Google has rewarded us $92,337 in kernelCTF. This writeup covers the technical details of the exploit.

Vulnerability Summary GhostLock (CVE-2026-43499) lets an unprivileged local attacker:

Get a dangling kernel pointer to kernel stack memory with only regular threading syscalls. Write a pointer to an almost arbitrary address. Hijack a function table to get control flow hijack and eventually get root access.

GhostLock was introduced in Linux 2.6.39 and fixed in Linux 7.1. It has existed in the Linux kernel for more than 15 years. Every Linux distribution without the patch is affected and should consider upgrading to the latest LTS version. Your browser does not support the video tag. Vulnerability Analysis OverviewGhostLock was introduced with the rtmutex rework in 8161239a8bcc (“rtmutex: Simplify PI algorithm and make highest prio task get lock”), and sat untouched for about fifteen years until the April 2026 fix in 3bfdc63936dd (“rtmutex: Use waiter::task instead of current in remove_waiter()”). The affected range is v2.6.39-rc1 to v7.1-rc1, with CONFIG_FUTEX_PI=y the only requirement and no capabilities or user namespaces needed.remove_waiter() in kernel/locking/rtmutex.c clears current->pi_blocked_on. That is correct on the normal slow path, where current is the task that owns the waiter. It is wrong on the proxy path. rt_mutex_start_proxy_lock() enqueues, and on error rolls back, an rt_mutex_waiter on behalf of another task, so current is the requeuer rather than the waiter.

The waiter object lives on the stack of a task sleeping in FUTEX_WAIT_REQUEUE_PI. A FUTEX_CMP_REQUEUE_PI then proxies that waiter onto the target PI futex. When the rtmutex chain walk reports a deadlock, the rollback dequeues the waiter from the lock but clears pi_blocked_on on the requeuer. The waiter task keeps pi_blocked_on pointing at its own stack frame, which is popped the moment the waiter returns to userspace. Any later PI chain walk through that task follows the dangling pointer.Root causeThis is the same shape as many other life-cycle bugs: a function reused by a caller it was never written for.The helper function remove_waiter() was originally written for exactly one scenario: a thread blocks on its own, then cleans up after itself. So it has always assumed that current (whichever thread happens to be running) is the waiter it needs to clean up, and clears current->pi_blocked_on accordingly.However, Requeue-PI breaks that assumption. Through rt_mutex_start_proxy_lock(), this helper is now used to clean up on behalf of a different, sleeping thread. In that path, current is the thread that issued FUTEX_CMP_REQUEUE_PI rather than the actual waiter.When __rt_mutex_start_proxy_lock() returns -EDEADLK, it rolls back via remove_waiter(), the misused helper.int __sched rt_mutex_start_proxy_lock(struct rt_mutex_base *lock, struct rt_mutex_waiter *waiter, struct task_struct *task){ int ret; raw_spin_lock_irq(&lock->wait_lock); ret = __rt_mutex_start_proxy_lock(lock, waiter, task); if (unlikely(ret)) remove_waiter(lock, waiter); // ret == -EDEADLK raw_spin_unlock_irq(&lock->wait_lock);

return ret;}remove_waiter() then scrubs the wrong task.static void __sched remove_waiter(struct rt_mutex_base *lock, struct rt_mutex_waiter *waiter){ ... raw_spin_lock(&current->pi_lock); rt_mutex_dequeue(lock, waiter); current->pi_blocked_on = NULL; // should be waiter->task raw_spin_unlock(&current->pi_lock); ...}waiter is the object that lives on the sleeping thread’s own stack, while current here is the thread that requested the requeue. The fix locks waiter->task->pi_lock and clears waiter->task->pi_blocked_on instead. This issue slips past lockdep, which only checks that a pi_lock is held but not whose it is.Triggering the -EDEADLK Path. Reaching the -EDEADLK rollback needs a PI dependency cycle built from three futex words and three threads. f_pi_chain, a PI futex, locked first by the waiter thread. f_pi_target, a PI futex, locked first by the owner thread. This is the requeue target. f_wait, the plain futex the waiter blocks on with FUTEX_WAIT_REQUEUE_PI. The sequence is: The waiter takes f_pi_chain, then blocks in FUTEX_WAIT_REQUEUE_PI(f_wait -> f_pi_target). Its rt_mutex_waiter is now on its stack. The owner takes f_pi_target, then blocks on f_pi_chain, which the waiter holds. The main thread calls FUTEX_CMP_REQUEUE_PI(f_wait -> f_pi_target). The requeue tries to proxy the waiter onto f_pi_target. The owner of f_pi_target is already blocked behind the waiter through f_pi_chain, so the chain walk closes the loop waiter -> f_pi_target -> owner -> f_pi_chain -> waiter. It returns -EDEADLK and takes the buggy rollback. The waiter wakes with a dangling pi_blocked_on.Here the only ordering that matters is the requeuer rolling back the waiter while the waiter still owns the soon-to-be-freed object, and once the cycle is staged that happens on its own.

After it resolves there is no time pressure at all. The waiter sits in userspace with a dangling pi_blocked_on, and the follow-up sched_setattr() that walks the chain can fire whenever it likes. The UAF window is wide open.The catch is where the freed object lives on the kernel stack (stack-UAF if we call ret out of the futex syscall a “free”). To reclaim it, we need to find a syscall that can land controlled bytes back on the same stack at the same depth (offset).Triggering the stack-UAFStaging the three-futex cycle leaves the waiter task in userspace with pi_blocked_on dangling into its old FUTEX_WAIT_REQUEUE_PI frame. Everything below rides on that one pointer. Note that three threads is for better understanding. To win the race and trigger UAF, you only need one CPU core. The initial primitive from GhostLock By now we hold a pointer into freed kernel stack, and we can trigger, at will, a kernel access that dereferences it as an rt_mutex_waiter. We can spray controlled bytes onto that stack and forge the rt_mutex_waiter outright. Depending on the shape we forge, this one access yields several primitives, two main ones:

write a pointer to an arbitrary (but constrained) address write 8 bytes of zero to an arbitrary (but constrained) address

Several pointer dereferences and integrity checks run before the primitive fires, and after it fires the kernel returns normally, no crash. So our main questions, each answered in a section below:

how do we get the freed stack memory back (spray)? -> Reusing the stack how do we get the fake rt_mutex_waiter past its built-in structural checks, and forge pointers that read as valid? -> From fake waiter to a write which write primitive, and what do we write where? what does the primitive constrain about the “arbitrary” address? -> Use inet6_protos

Exploit Details Exploit Summary

prefetch -> Leak the kernel image slide and the physmap base. GhostLock -> Leave a dangling rt_mutex_waiter in the waiter task’s pi_blocked_on. (stack-)UAF Reclaim -> Use PR_SET_MM_MAP to reclaim the waiter’s own kernel stack and forge a fake rt_mutex_waiter over the freed frame.

Arb address writer -> Rtmutex rb-tree erase: one constrained pointer write (which we can reclaim its content), overwrite struct which contains a function table: inet6_protos[IPPROTO_UDP] = <CEA pointer>. CPU entry area -> Host {fake inet6_protocol, pivot slots, ROP stack} all together at a known direct-map address. Trigger CFH -> Trigger a loopback IPv6 UDP packet calls through the overwritten handler and pivots. DirtyMode -> One write flips core_pattern’s mode bits, then the rest LPE is pure userspace.

What about Android? This part we are focusing on basic exploit steps of generic x86 Linux systems, our next blog will discuss how to exploit GhostLock on Android, reclaiming stack frame, bypassing both ASLR and CFI. Background of used tricksPrefetch ASLR LeakA prefetch on a given address runs in a different number of cycles depending on whether that address is mapped in the current page tables, so an unprivileged process can time prefetch across the kernel range and read off which addresses are mapped (the prefetch paper has the details).It works here as Linux barely randomizes the base of its default kernel image (~9 bits of entropy for text base), so a little averaging can recover the KASLR base with near 100% reliability.In theory any CPU with prefetch and without proper Kernel Page-Table Isolation is affected. But in practice it is more of an x86 technique (unless the ARM target runs KPTI off). kernelCTF images keep KPTI disabled. kernelCTF images keep KPTI disabled, but even with KPTI on, prefetch paired with EntryBleed can still recover the kernel image base through the trampoline. CEA spray and randomization bypassThe CEA (CPU entry area) is a per-CPU x86 structure holding the stacks and register context used for entry and exception handling: on an exception, interrupt, or syscall the CPU switches to a stack that lives in the CEA, and the entry code spills the register frame (pt_regs) there. An unprivileged userspace program can trigger a software exception and write its own register context into the pt_regs saved on a CEA exception stack.

Before 6.2 the CEA sat at a completely fixed address, so we can place about 120 bytes of contiguous controlled memory at a known kernel address, which is very handy for forging structures, for absorbing the side effects of the pointer dereferences along the way, and for staging a ROP stack.After Project Zero’s Bringing back the stack attack writeup, the kernel started strongly randomizing the CEA’s virtual address (since 6.2). But the virtual address of the CPU entry area is never needed, as the CEA’s physical offset is fixed, so its direct-map alias follows from the physmap base (same observation @kqx used).That direct-map address is easy to leak with prefetch, plus candidate-edge normalization and a check against the predicted CEA page to reject neighbouring aliases. (The direct-map leak is noisier than the text one and may need a little more tuning, but it lands at very high accuracy on the target in the end.) So we can always compute the CEA’s other virtual-address mapping:cea_direct = physmap_base + CPU1_CEA_BASENote that each CPU’s CEA virtual address is randomized to a different place. Their physical addresses are all fixed, though, and this offset depends mainly on the target’s kernel version and boot memory size. In the kernelCTF LTS 6.12.80 3.5G-boot environment, it is 0x11c517000(+0x1f58). Reusing the stack: forging the waiter with PR_SET_MM_MAP The dangling object is the waiter’s own stack rt_mutex_waiter. struct rt_mutex_waiter { struct rt_waiter_node tree; // rb node, lives in lock->waiters struct rt_waiter_node pi_tree; struct task_struct *task; struct rt_mutex_base *lock; unsigned int wake_state; struct ww_acquire_ctx *ww_ctx;}; Controlled bytes have to land back over that exact frame, on the waiter thread’s own stack, and stay there long enough to be read. The waiter thread returns from the futex syscall and immediately calls prctl(PR_SET_MM, PR_SET_MM_MAP, ...).