Nebula Security has disclosed GhostLock (CVE-2026-43499), a stack use-after-free in the Linux kernel's real-time mutex (rtmutex) priority-inheritance code that has existed in every mainstream distribution for roughly 15 years. Any logged-in local user can exploit it to gain full root — no special privileges, no unusual configuration, and no network access are required — and the same bug can be used to escape a container onto the host. The researchers built a working exploit that is 97% reliable in their testing, and they have published the exploit code, so any local attacker can now run it. The upstream kernel quietly fixed the root cause in April 2026, but a large population of servers running older or un-updated kernels remains exposed. There are no confirmed in-the-wild attacks yet, but with public PoC available, patching is now urgent.

What the Vulnerability Is

The bug lives in the kernel's rtmutex subsystem, which handles priority inheritance — the mechanism that keeps an urgent thread from being blocked indefinitely by a lower-priority thread holding a lock. Part of the cleanup path, a function called remove_waiter(), was written on the assumption that the thread cleaning up a lock is always the same thread that was waiting on it (current).

A feature called Requeue-PI broke that assumption years ago: it allows one thread to perform cleanup on behalf of another. The cleanup code was never updated to match. The result is a use-after-free: the kernel holds a pointer to a chunk of stack memory that belongs to a sleeping thread and has already been freed and reused. By racing ordinary threading/futex calls, a local attacker can groom that freed stack memory and steer kernel execution into taking control of the machine.

Because rtmutex priority inheritance is core kernel plumbing reachable through normal userspace threading primitives, exploitation needs nothing exotic — "ordinary threading calls from any local program are enough," per Nebula. Google awarded the team $92,337 through its kernelCTF program for the finding.

Why It Matters

  • Trivial preconditions. Any unprivileged local account can attempt it. No misconfiguration, kernel module, or elevated capability is needed.
  • Container escape. The same primitive breaks out of containers onto the host — a direct threat to multi-tenant Kubernetes nodes, Docker hosts, and shared-container platforms.
  • Public, reliable exploit. Working PoC code is published and ~97% reliable, collapsing the gap between disclosure and mass exploitation.
  • Enormous, aged install base. The vulnerable code shipped by default across distributions since ~2011, so long-lived and rarely-rebooted servers are prime targets.
  • High-value on shared hosting and CI. Anywhere untrusted local code runs — shared/reseller hosting, CI/CD runners, sandboxes, VPS containers — a low-privilege foothold becomes full root.

Am I Affected?

You are likely exposed if:

  • You run a Linux server on a kernel that predates the April 2026 rtmutex fix (or a distro kernel that has not yet backported it), and
  • Untrusted or semi-trusted users can execute code locally — shared hosting accounts, container tenants, CI runners, web-app shells, or any service that could be leveraged for local code execution after a lesser compromise.

Container hosts are a specific concern: an attacker who lands code inside one container can use GhostLock to reach the host and every other tenant on it.

You are not meaningfully exposed if the box runs only trusted first-party code and has no path to local code execution — but treat that as defense-in-depth, not a reason to skip patching.

What to Do About It: Step-by-Step

  1. Patch the kernel (primary fix). Update to a distro kernel that includes the April 2026 rtmutex fix (and its follow-up hardening — the first patch introduced a separate null-pointer corner case that required a second fix). Apply vendor updates and reboot: 
    # Debian / Ubuntu
sudo apt update && sudo apt full-upgrade
sudo reboot

# RHEL / Alma / Rocky
sudo dnf update kernel
sudo reboot

# check running kernel after reboot
uname -r
  2. Confirm you actually rebooted into the new kernel. A patched package on disk does nothing until you boot into it: 
    uname -r                          # running kernel
rpm -q kernel 2>/dev/null || dpkg -l | grep linux-image   # installed kernels
  3. If you cannot reboot immediately, use live patching where available. kpatch (RHEL/Alma/Rocky), Canonical Livepatch (Ubuntu), or your provider's live-patch service can close the window without a reboot on supported kernels.
  4. Harden container hosts in the meantime. Reduce blast radius: run workloads as non-root, apply restrictive seccomp/AppArmor/SELinux profiles, avoid --privileged containers, and keep untrusted tenants on separately-patched nodes.
  5. Tighten who can run local code. On shared hosting and CI, minimize interactive/local execution surface, keep runners ephemeral, and rotate/rebuild any long-lived hosts promptly after patching.
  6. Watch for exploitation attempts. Monitor for unexpected privilege transitions, crashes/oops in rtmutex/futex paths, and new root processes spawned from unprivileged accounts.

Quick-Win Checklist

  • Identify all Linux hosts and their running kernel versions (uname -r).
  • Apply the latest distro kernel update including the April 2026 rtmutex fix + follow-up.
  • Reboot (or apply live patch) and verify the new kernel is running.
  • Prioritize container hosts, shared hosting, and CI/CD runners.
  • Enforce non-root workloads and seccomp/MAC profiles on container nodes.
  • Rebuild ephemeral runners; rotate long-lived shared hosts.
  • Monitor for anomalous privilege escalation and rtmutex/futex kernel errors.

Sources