GhostLock: A 15-Year Linux Kernel Vulnerability That Affects Every Distribution

A vulnerability called GhostLock (CVE-2026-43499) has been hiding in the Linux kernel for 15 years. The bug - a stack use-after-free in the real-time mutex (rtmutex) implementation - affects virtually every Linux distribution and earned its discoverers $92,337 from Google's kernelCTF competition.

The vulnerability was introduced in Linux 2.6.39-rc1 and fixed in Linux 7.1-rc1. If your system hasn't been patched, it's affected.

What GhostLock Actually Does#

The bug lives in a function called remove_waiter(). Originally, this helper was designed for a task to clean up after itself when it stopped waiting on a mutex. The problem emerged when the Requeue-PI functionality started using this same function through rt_mutex_start_proxy_lock().

The core issue: when remove_waiter() clears the pi_blocked_on pointer, it targets the wrong task. The waiter object lives on the stack of a sleeping task, but the function clears the pointer on the requeuer instead of the actual waiter. This mismatch creates a dangling pointer.

Nebula Security's research team discovered the bug using their internal tool VEGA. They reported it on April 18, 2026, and it was fixed two days later on April 20. The public disclosure came on July 7.

The Exploitation Path#

The researchers achieved 97% stability for privilege escalation and container escape - no special privileges or unusual kernel configurations required. The exploit works with ordinary threading syscalls.

Here's the high-level attack chain:

1. Trigger the bug using three futexes and a deadlock cycle detection that returns -EDEADLK
2. Leak kernel ASLR using a prefetch-based side channel to determine the kernel image offset
3. Spray the CPU entry area to reclaim the freed stack frame with controlled data
4. Overlay controlled data via PR_SET_MM_MAP to place attacker-controlled bytes where the freed waiter structure lived
5. Hijack control flow by overwriting inet6_protos through rtmutex rb-tree manipulation
6. Flip permission bits using the DirtyMode technique on /proc/sys/kernel/core_pattern

The researchers note this follows "the same shape as many other life-cycle bugs" - a helper function gets repurposed beyond its original design, and the assumptions it makes no longer hold.

Affected Systems#

Any Linux kernel version from 2.6.39-rc1 through 7.1-rc1 with CONFIG_FUTEX_PI=y enabled is vulnerable. This covers essentially every mainstream distribution released in the last 15 years.

The researchers tested the exploit on three Android devices running versions 9, 13, and 16. Two boot-looped into recovery mode; the third powered off. A demo on supported Pixel devices modifies the wallpaper as proof of concept.

What HN Is Saying#

The Hacker News discussion is lively, with several threads worth noting.

On the discovery method: Some commenters are questioning whether "use after free" became common terminology because of LLMs, while others point out it's been standard security parlance for decades. The writing style of the research paper itself drew comparisons to Claude's output patterns.

On Linux security broadly: One commenter asked whether we "really need infosec companies now that a skid with Claude can find decades-old kernel privesc over a weekend." Others pushed back on Linux security in general, pointing to OpenBSD as an alternative for security-critical workloads.

On Android implications: Several developers are asking whether this could be used to unlock bootloaders on typically locked phones. Others wonder if SELinux provides any protection (the research suggests the exploit bypasses typical kernel protections).

On the severity: The $92,337 payout from Google's kernelCTF speaks to the severity. As one commenter put it after seeing the reward amount: "I'm all ears now."

The Fix#

The patch corrects remove_waiter() to clear pi_blocked_on on the actual waiter task rather than current. The fix passes the correct task context through the call chain and uses the waiter's task lock for synchronization.

If you're running Linux in production, check your kernel version and ensure you're on a patched release. The major distributions have all shipped updates.

Why This Matters for Developers#

Three takeaways from GhostLock:

Helper functions are risk magnets. When a function gets reused beyond its original scope, the assumptions it makes may no longer hold. The original remove_waiter() code was correct for its intended use case - the bug emerged from repurposing it.

Life-cycle bugs are subtle. The mismatch between which task owns the waiter object and which task is current during cleanup is exactly the kind of semantic confusion that static analysis struggles to catch. Code review and fuzzing remain essential.

Kernel security is everyone's problem. If you're running containers, VMs, or any workload where tenant isolation matters, kernel vulnerabilities like this represent a shared attack surface. Container escapes mean your isolation guarantees are only as good as your kernel patches.

The research paper at nebusec.ai includes full technical details, including the ION-related exploitation techniques that give the research its "IonStack" name.

Sources#

• GhostLock Research Paper - Nebula Security
• Hacker News Discussion - 385 points, 181 comments
• Use After Free (Wikipedia) - Background on UAF vulnerabilities