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.

Vulnerability Analysis

I would like to see the exploit strategy directly

Overview

GhostLock 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 cause

This 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.

1
int __sched rt_mutex_start_proxy_lock(struct rt_mutex_base *lock,
2
                                      struct rt_mutex_waiter *waiter,
3
                                      struct task_struct *task)
4
{
5
  int ret;
6
  raw_spin_lock_irq(&lock->wait_lock);
7
  ret = __rt_mutex_start_proxy_lock(lock, waiter, task);
8
  if (unlikely(ret))
9
    remove_waiter(lock, waiter);          // ret == -EDEADLK
10
  raw_spin_unlock_irq(&lock->wait_lock);
11
  return ret;
12
}

remove_waiter() then scrubs the wrong task.

1
static void __sched remove_waiter(struct rt_mutex_base *lock,
2
                                  struct rt_mutex_waiter *waiter)
3
{
4
  ...
5
  raw_spin_lock(&current->pi_lock);
6
  rt_mutex_dequeue(lock, waiter);
7
  current->pi_blocked_on = NULL;            // should be waiter->task
8
  raw_spin_unlock(&current->pi_lock);
9
  ...
10
}

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:

1. 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.
2. The owner takes f_pi_target, then blocks on f_pi_chain, which the waiter holds.
3. 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-UAF

Staging 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.

1
cea_direct = physmap_base + CPU1_CEA_BASE

Reusing the stack: forging the waiter with PR_SET_MM_MAP

The dangling object is the waiter’s own stack rt_mutex_waiter.

1
struct rt_mutex_waiter {
2
  struct rt_waiter_node tree;     // rb node, lives in lock->waiters
3
  struct rt_waiter_node pi_tree;
4
  struct task_struct *task;
5
  struct rt_mutex_base *lock;
6
  unsigned int wake_state;
7
  struct ww_acquire_ctx *ww_ctx;
8
};

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, ...). Inside, prctl_set_mm_map() copies a user-supplied auxv into a fixed-size unsigned long user_auxv[AT_VECTOR_SIZE] stack buffer. That buffer sits at roughly the same stack depth as the freed waiter, so it is a large, naturally-aligned, namespace-free block of controlled qwords landing right on top of the old object.

The auxv is laid out so the overlapping qwords become:

• tree, an rb node shaped so erasing it promotes one chosen child pointer (W0_BASE, below) into the tree root.
• task, set to &init_task, a valid task_struct so the chain walk’s task derefs are safe.
• lock, set to &inet6_protos[IPPROTO_UDP] - 8, the write target.
• wake_state, set to 0.

The auxv is backed by a memfd and positioned so the copy straddles a page boundary. A sibling thread races fallocate(PUNCH_HOLE) on the trailing page during the prctl, which stretches the copy_from_user window. The forged waiter stays live on the stack while, on another CPU, a consumer thread fires sched_setattr() on the waiter to walk the PI chain.
The race window is wide and we believe GhostLock is also exploitable on a single-core CPU.

clone/setsockopt/pselect/keyctl and other syscalls with large controlled stack locals work the same way. prctl is just convenient here. The buffer is large, aligned, and needs no namespace.
Here’s more useful syscalls that can reclaim the stack frame in our open-sourced PoC code.

From fake waiter to one controlled (limited) write

Controlling the waiter does not give an arbitrary write. The chain walk only does:

1
task->pi_blocked_on -> fake waiter
2
fake waiter->lock    -> fake rt_mutex_base
3
rt_mutex_dequeue(lock, waiter)        // rb_erase on lock->waiters

rt_mutex_dequeue() is an rb-tree erase, and erasing a single-child root writes that child into the root slot. Pointing lock at target - 8 lines the rt_mutex_base fields up over the data around the target pointer.

1
target - 8  ->  raw_spinlock_t wait_lock        (must read as "unlocked")
2
target      ->  waiters.rb_root.rb_node          (this slot gets written)
3
target + 8  ->  waiters.rb_leftmost
4
target + 16 ->  owner

The fake waiter’s rb node is shaped so the erase writes exactly one child pointer into rb_root.rb_node. The write primitive itself is a single constrained store: *(uint64_t *)target = W0_BASE.

The constraints are also highly strict: The qword before the target must read as an unlocked spinlock, meaning zero in the low 4 bytes, or the trylock fails and the walk exits without writing. The qwords after it (rb_leftmost, owner) must not steer the walk into an uncontrolled top waiter or owner. An unmapped value there faults and panics the box. The equivalent target address constraint is roughly as follows (*target will be written to a pointer):

1
*(u32 *)(target - 0x08) == 0
2
*(u64 *)(target + 0x08) == 0 // simplified
3
((*(u64 *)(target + 0x10)) & ~1ULL) == 0
4
// Then we can do:
5
*(u64 *)target = &W0->tree.entry  // W0_BASE

Here the W0_BASE has to point at something that stays valid through the comparisons and the no-owner wakeup later in the same rt_mutex_adjust_prio_chain(). We point it at the direct-map alias of the CPU entry area, which pays off twice:

• Before the write: the CEA is controllable memory at a known address, so we can forge a self-consistent fake waiter and lock at W0 that survives the walk.
• After the write: the target now points into the CEA. Once the walk is over, W0 no longer has to look like a waiter at all, so we can re-spray the CEA with whatever the kernel expects the target to point at (if we overwritten a function table pointer with W0, we can now fake function pointer in CEA to get Control Flow Hijack).

Before the trigger, W0 is spraied as that fake waiter and lock pair: task = &init_task, a legit prio, and a lock whose wait_lock reads unlocked and whose owner is benign, so the dequeue, re-enqueue, priority update and wakeup all survive.

The following figure shows how CPU entry area is used to first hold fake rt_mutex_waiter and lock structures, then serve inet6 (next section), ROP stack and JOP gadgets for stack pivoting at the same time, and eventually use a very short ROP to perform the DirtyMode and safely halt the core.

Use inet6_protos[IPPROTO_UDP] to help

Start from now the exploit path would differ from targets, as of regular x86_64 Linux kernel, we can pick a shorter path by just overwriting some function table (or any object that contains one), as we already have KASLR leaked and ready to get a CFH.

A scan of writable data turns up many pointer tables whose neighbours satisfy the layout above. inet6_protos[IPPROTO_UDP] is a nice one. The neighbours fall out for free, and the trigger is a trivial unprivileged loopback packet.

1
inet6_protos[16]  == NULL              // fake wait_lock -> unlocked
2
inet6_protos[17]  == &udpv6_protocol   // <- target (IPPROTO_UDP)
3
inet6_protos[18]  == NULL              // fake rb_leftmost
4
inet6_protos[19]  == NULL              // fake owner

After the write, inet6_protos[IPPROTO_UDP] points into the CEA page, where the kernel expects an inet6_protocol.

1
struct inet6_protocol {
2
  int (*handler)(struct sk_buff *skb);
3
  int (*err_handler)(...);
4
  unsigned int flags;
5
};

So W0 is re-spraied as a fake inet6_protocol. handler is the first pivot gadget, err_handler is unused, and flags is INET6_PROTO_NOPOLICY | INET6_PROTO_FINAL. Once we send a loopback IPv6 UDP (connect then write to ::1), the kernel will dereference the handler and give us a PC control.

The pivot and DirtyMode

We use the same compact CEA window to holds multiple objects: {the fake inet6_protocol, a few JOP/pivot slots, the final ROP stack}. On Google’s lts-6.12.80 kernel target we are not lucky enough to find a nice single stack pivot target, so the chain takes one extra load/call to land the CEA address in rbp, then pivots with mov rsp, rbp; pop rbp; ret.

A ret2usr or a full /proc/%P/fd/x overwrite would run to around ten gadget qwords, which is too long. So we use DirtyMode as the final exploit stage: a single write, with an almost-garbage value, that flips a permission bit. After it, LPE can be done purely in userspace.

Here we target at the core_pattern sysctl’s mode flags:

1
static struct ctl_table coredump_sysctls[] = {
2
  ...
3
  { .procname     = "core_pattern",
4
    .data         = core_pattern,
5
    .maxlen       = CORENAME_MAX_SIZE,
6
    .mode         = 0644,
7
    .proc_handler = proc_dostring_coredump },
8
  ...
9
};

coredump_sysctls lives in writable kernel data (share same KASLR slide with kernel image). The ROP writes a permissive value to coredump_sysctls[1].mode. Any value with the write bit (2nd LSB) set is enough.

Here we uses a short pop reg; mov [reg], reg; ret plus an msleep to park the hijacked thread safely. And now /proc/sys/kernel/core_pattern is now world-writable, so an unprivileged process opens it, writes |/proc/%P/fd/666 %P, and crashes a helper to trick kernel runs our binary as root.

The initial write primitive (the rb-tree write) cannot reach coredump_sysctls[1].mode directly because of where it lands, so the mode flip is done from the short ROP stage.

Appendix

The full exploit code can be found in our open source security research project, CyberMeowfia.

bigger ROP or NPerm

kernelCTF is a race, and the shortest reliable chain wins. NPerm-backed memory makes a fine large fake stack after the hijack, and there are heavier routes that would also work, including Lukas Maar’s heap-KASLR leak. Each adds another stage and increases time cost. CEA plus DirtyMode is the shortest path to a one-write win, and on the remote it win us the flag in about 5 seconds.

Mitigation

The patch

1
diff --git a/kernel/locking/rtmutex.c b/kernel/locking/rtmutex.c
2
--- a/kernel/locking/rtmutex.c
3
+++ b/kernel/locking/rtmutex.c
4
@@ -1544,6 +1544,8 @@ static bool rtmutex_spin_on_owner(struct rt_mutex_base *lock,
5
  *
6
  * Must be called with lock->wait_lock held and interrupts disabled. It must
7
  * have just failed to try_to_take_rt_mutex().
8
+ *
9
+ * When invoked from rt_mutex_start_proxy_lock() waiter::task != current !
10
  */
11
 static void __sched remove_waiter(struct rt_mutex_base *lock,
12
           struct rt_mutex_waiter *waiter)
13
@@ -1551,14 +1553,15 @@ static void __sched remove_waiter(struct rt_mutex_base *lock,
14
 {
15
   bool is_top_waiter = (waiter == rt_mutex_top_waiter(lock));
16
   struct task_struct *owner = rt_mutex_owner(lock);
17
+  struct task_struct *waiter_task = waiter->task;
18
   struct rt_mutex_base *next_lock;
19

20
   lockdep_assert_held(&lock->wait_lock);
21

22
-  raw_spin_lock(&current->pi_lock);
23
-  rt_mutex_dequeue(lock, waiter);
24
-  current->pi_blocked_on = NULL;
25
-  raw_spin_unlock(&current->pi_lock);
26
+  scoped_guard(raw_spinlock, &waiter_task->pi_lock) {
27
+    rt_mutex_dequeue(lock, waiter);
28
+    waiter_task->pi_blocked_on = NULL;
29
+  }
30

31
   /*
32
    * Only update priority if the waiter was the highest priority
33
@@ -1594,7 +1597,7 @@ static void __sched remove_waiter(struct rt_mutex_base *lock,
34
   raw_spin_unlock_irq(&lock->wait_lock);
35

36
   rt_mutex_adjust_prio_chain(owner, RT_MUTEX_MIN_CHAINWALK, lock,
37
-           next_lock, NULL, current);
38
+           next_lock, NULL, waiter_task);

This patch is effective at mitigating the exploit, though it missed a scenario that produces an NPD: a non-top requeue waiter that already owns the target PI futex hits -EDEADLK before waiter->task is set, so the new remove_waiter() then dereferences a NULL waiter->task.

We had also sent a fix to security@kernel.org before v1 landed. Its core:

1
static void __sched remove_waiter(struct rt_mutex_base *lock,
2
          struct rt_mutex_waiter *waiter)
3
          struct rt_mutex_waiter *waiter,
4
          struct task_struct *task)
5
{
6
  ...
7
  raw_spin_lock(&current->pi_lock);
8
  raw_spin_lock(&task->pi_lock);
9
  rt_mutex_dequeue(lock, waiter);
10
  current->pi_blocked_on = NULL;
11
  raw_spin_unlock(&current->pi_lock);
12
  if (task->pi_blocked_on == waiter)
13
    task->pi_blocked_on = NULL;
14
  raw_spin_unlock(&task->pi_lock);
15
  ...
16
  rt_mutex_adjust_prio_chain(owner, RT_MUTEX_MIN_CHAINWALK, lock,
17
           next_lock, NULL, current);
18
           next_lock, NULL, task);
19
}

Instead of reading the task out of waiter->task, the callers pass in the owning task (current on the self-blocking path, the proxied task on the rt_mutex_start_proxy_lock() rollback), and pi_blocked_on is cleared only when it still points at this waiter. task is always a valid task and the clear is guarded, so this closes the UAF without opening the -EDEADLK NULL dereference, and needs no follow-up like 74e144274af3. It carries a small, benign behavioral quirk with no impact on normal use or security. Upstream preferred the waiter::task rewrite in v1.

RANDOMIZE_KSTACK_OFFSET

The stack-reuse step relies on the freed waiter frame and the later user_auxv frame overlapping deterministically. With RANDOMIZE_KSTACK_OFFSET on they no longer do, and the step becomes a roughly 1/32 (5-bit) stack-offset guess. Both submitted targets leave it off by default. The mitigation target turns it on, so this path was not used there.

STATIC_USERMODE_HELPER

STATIC_USERMODE_HELPER would close this particular DirtyMode path. But the same idea can be generalized to any /proc/sys knob whose ctl_table::mode gates access and whose table sits in predictable writable kernel data.

Timeline

• 2026-04-18: We reported the bug and sent a draft patch to security@kernel.org.
• 2026-04-20: The bug was fixed with another patch.
• 2026-05-04: The fix v1 was backported.
• 2026-06-30: Google acknowledged our kernelCTF submission and rewarded us $92,337.
• 2026-07-07: We published this blog post.

Disclosure policy

For all bugs found by VEGA, we follow our standard 90+30 days disclosure policy as described on our About page.