A 15-year-old Linux kernel bug called GhostLock hands any logged-in user root

Nebula Security disclosed a Linux kernel flaw on July 7 that does something ordinary and dangerous: it lets a user who is already logged in become root. GhostLock, filed as CVE-2026-43499, needs no special permission, no unusual configuration, and no network access. The researchers' public exploit is 97% reliable in their own testing and takes about five seconds on their test machine. It also escapes containers, which is the part that should worry anyone running shared infrastructure.

The bug scores 7.8 out of 10. That is high, not critical, and the reason for the gap matters: an attacker has to already have a foothold on the machine. GhostLock does not get you in. It takes whatever access you have and turns it into everything.

What it actually is

The flaw lives in the kernel's real-time mutex code, on the futex priority-inheritance path that keeps an urgent thread from getting stuck behind a lower-priority one. AlmaLinux's writeup points at the exact spot: a helper called remove_waiter() in rtmutex.c assumes the waiter it is cleaning up belongs to the currently running task. In one requeue path, FUTEX_CMP_REQUEUE_PI, the kernel hits a deadlock cycle, rolls back with -EDEADLK, and clears the bookkeeping on the wrong thread. That leaves a pointer into a piece of kernel stack memory that has already been freed and reused. Trusting that stale pointer is the whole bug, a stack use-after-free.

From that one bad write, Nebula's team reclaimed the freed memory with a forged structure, walked it up to arbitrary kernel read and write, and hijacked control flow to run code as root. None of the individual steps are new. Chaining them into something 97% reliable is the work.

The code has been there since 2011, in Linux 2.6.39. It depends only on CONFIG_FUTEX_PI, which distributions turn on by default, so the exposure is about as wide as kernel bugs get. Fifteen years is a long time for a reachable local root to sit in a subsystem this heavily used.

Why "local only" undersells it

Two things push GhostLock past the usual privilege-escalation shrug.

The first is container escape. The same exploit that gets root on a host also breaks out of a container to the host underneath it. On a cloud box, a CI runner, or any multi-tenant machine, that collapses the boundary the tenants are paying to keep.

The second is what Nebula bolted it onto. GhostLock is the back half of a chain the company calls IonStack. The front half is a Firefox flaw, CVE-2026-10702, that runs code inside the browser and escapes its sandbox. GhostLock carries that from the browser the rest of the way to root. Nebula says it demonstrated the full path, from a single tap on a malicious link to full device control, against Firefox on Android. A local-only kernel bug stops looking local once a browser exploit is handing it the foothold.

An AI tool found it, and that is becoming the pattern

Nebula credits the find to VEGA, its automated analysis tool, and says Google paid the team $92,337 through the kernelCTF bug-bounty program. Read that number as a signal rather than a headline: kernelCTF pays real money for working, reliable kernel exploits, and an automated tool just collected a full payout.

GhostLock is not alone. Days earlier, researchers disclosed Bad Epoll (CVE-2026-46242), a close cousin in a different corner of the kernel that also turns an unprivileged user into root and, unusually, works on Android. Anthropic's Mythos model was credited with a related flaw in the same neighborhood. The common thread is old, heavily used machinery that few people had reread in years, until tools started combing through it line by line. Futex priority inheritance dates to 2011. Nobody was looking at it. Now something is.

This is good work, and it cuts both ways. The same tooling that lets a defender find a 15-year-old bug before an attacker does also lowers the bar for finding the next one. For now the disclosures are landing with fixes attached. That will not always hold.

Patch status, and a trap in it

GhostLock was reported privately, fixed in mainline in April (commit 3bfdc63936dd, Linux 7.1), and disclosed publicly this week with working exploit code on GitHub. No one is known to be exploiting it in the wild yet. The public code changes that math, so patching is the job now.

One catch: do not install the first patched build you see and call it done. The original fix introduced a separate crash bug, CVE-2026-53166, and the cleanup for that was still settling upstream in early July. Take your distribution's current kernel, not the earliest one that claims to close GhostLock.

AlmaLinux moved ahead of its own upstream and shipped patched kernels to its testing repository on July 9, with a call for the community to verify them before they reach production. The fixed versions it lists:

• AlmaLinux 8: kernel-4.18.0-553.141.2.el8_10 or higher
• AlmaLinux 9: kernel-5.14.0-687.23.2.el9_8 or higher
• AlmaLinux 10: kernel-6.12.0-211.31.2.el10_2 or higher

Coverage elsewhere is uneven. In early July, Ubuntu had patched its newest release and some cloud kernels but still listed 24.04, 22.04, and 20.04 LTS as vulnerable or in progress. Check your distribution's advisory and confirm the exact fixed package version rather than assuming one is waiting for you.

There is no clean workaround, because the operations that trigger the bug are routine for any local process. Two build-time options, RANDOMIZE_KSTACK_OFFSET and STATIC_USERMODE_HELPER, make the exploit harder without fixing it. Patch the machines where an attacker is most likely to already have a toehold first: cloud servers, containers, and CI runners.