GhostLock kernel container escape breaks the agent sandbox assumption
A 15-year-old Linux futex use-after-free disclosed on 8 July 2026 gives an unprivileged local user root and escapes containers — the exact isolation layer most agentic code-execution sandboxes lean on.
What is this?
On 8 July 2026, Nebula Security disclosed GhostLock, a use-after-free in the Linux kernel’s real-time mutex (rtmutex) priority-inheritance code. An unprivileged local user can exploit it to gain root — and, crucially for anyone running AI agents, it works from inside a container to escape to the host. The bug was introduced in 2011 (Linux 2.6.39) and sat unread for roughly fifteen years until an automated analysis tool surfaced it. It is now fixed in mainline (commit 3bfdc63936dd, Linux 7.1), and distributions began shipping patches the same week; AlmaLinux published its advisory on 9 July.
We are not covering this as a kernel-security curiosity. We are covering it because container isolation is the load-bearing assumption under almost every agentic code-execution sandbox — the box where a coding agent runs generated scripts, where a tool-using agent evaluates untrusted code, where a CI runner executes an AI-authored job. GhostLock is a reliable, capability-free way out of that box, and a working exploit is already public.
How it works
The flaw lives in kernel/locking/rtmutex.c, on the futex priority-inheritance path. A cleanup helper (remove_waiter()) assumes the waiter it tidies up belongs to the currently running task. In the FUTEX_CMP_REQUEUE_PI requeue path, the kernel sometimes has to unwind on behalf of a different, sleeping thread after it detects a deadlock cycle and rolls back with -EDEADLK. During that rollback it clears the wrong task’s pi_blocked_on, leaving a dangling pointer into freed kernel stack memory — a stack use-after-free.
To trigger it, an attacker arranges three futexes and a set of coordinated threads into a priority-inversion deadlock, then reclaims the freed stack frame with a forged waiter structure. From there the public write-up chains a constrained write into arbitrary kernel read/write, hijacks control flow, and lands as root. Nebula reports the exploit is 97% reliable and completes in about five seconds on its test machine, and says Google awarded the team $92,337 through the kernelCTF program. The only precondition is the ability to run ordinary threading calls as a local process — no special capabilities, no unusual configuration. Exposure is broad because the code path only depends on CONFIG_FUTEX_PI, enabled on essentially every distribution kernel. We omit the exploitation primitives; the mechanism above is drawn entirely from the public disclosure.
Why it matters
For an agent platform, “an attacker needs a local foothold” is not the reassurance it sounds like. The whole point of a code-execution sandbox is to grant untrusted code a local foothold on purpose and rely on the container boundary to keep it there. A prompt-injected coding agent, a malicious skill, or an attacker-supplied test fixture that reaches code execution inside the container is already in exactly the position GhostLock needs. From there the container-to-host escape converts “the agent ran something it shouldn’t have inside its sandbox” into “the agent’s sandbox no longer exists.” On shared and multi-tenant infrastructure — hosted agent runtimes, CI, notebook backends — that means crossing from one tenant’s job into the host and potentially every other tenant on it.
Two contextual notes reinforce the point without overstating it. First, GhostLock is the kernel half of a chain Nebula calls IonStack: paired with a browser sandbox-escape flaw, a single tap on a malicious link was carried all the way to root on Android — a reminder that a “local-only” bug becomes remote when bolted onto an earlier stage. Second, the bug was found by an AI-driven analysis tool combing old kernel machinery, part of a 2026 run of similar futex/locking privilege-escalation findings. The honest limits: it is rated 7.8 (high, not critical) precisely because it needs local execution, no in-the-wild exploitation is known yet, and patched kernels exist. The exploit’s public availability is what moves the timeline.
Defenses
The lesson for agent operators is that the container boundary is a control that can fail, so it should never be the only thing between untrusted execution and the host:
- Patch the kernel on every host that runs agent workloads first. Install your distribution’s current kernel, not just the first patched build — the original fix introduced a separate crash bug (see Status), so early builds may lack the final version. Prioritize multi-tenant agent runtimes, CI runners, and notebook/code-interpreter backends.
- Do not treat containers as a security boundary on their own. Put a second layer under agent code execution — a virtualization-based sandbox (microVM / gVisor-style) or a dedicated, disposable VM per untrusted job — so a kernel escape does not immediately reach a shared host.
- Minimize what a compromised sandbox can reach. Give agent execution environments no ambient cloud credentials, no host mounts, and no lateral network path; assume the sandbox may be breached and scope blast radius accordingly.
- Harden the build config.
RANDOMIZE_KSTACK_OFFSETandSTATIC_USERMODE_HELPERmake this specific exploit harder. They are mitigations, not fixes, and do not replace patching. - Monitor for privilege escalation, not just prompt anomalies. Runtime detection on agent hosts should watch for kernel-level escalation and unexpected root transitions, not only the model-facing signals — the harmful step here happens well below the LLM.
Status
| Item | Detail |
|---|---|
| Name | GhostLock |
| Reference | CVE-2026-43499 (NVD) — CVSS 7.8 (high) |
| Type | Stack use-after-free, kernel rtmutex / futex priority-inheritance (FUTEX_CMP_REQUEUE_PI) |
| Impact | Unprivileged local root and container-to-host escape |
| Introduced | Linux 2.6.39 (2011); ~15 years unnoticed |
| Fixed | Mainline commit 3bfdc63936dd, Linux 7.1; distro backports from w/c 7 Jul 2026 |
| Discovery | Nebula Security, via AI-driven analysis tool “VEGA”; reported to security@kernel.org |
| Exploit | Public PoC; ~97% reliability, ~5s; Google kernelCTF award $92,337 |
| Caveat | Follow-up fix advised for a separate crash regression (CVE-2026-53166) introduced by the initial patch |
| In the wild | No known exploitation as of disclosure (8 Jul 2026) |