- CVE: CVE-2026-43499
- CVSS: 7.8 (High · CVSSv3)
- Product: Linux
- Affected: 8161239a8bcce9ad6b537c04a1fa3b5c68bae693, 2.6.39
- Impact: rtmutex: Use waiter::task instead of current in remove_waiter()
- Status: No confirmed exploitation yet
- Patched in: d8cce4773c2b23d819baf5abedc62f7b430e8745, 8a1fc8d698ac5e5916e3082a0f74450d71f9611f, 6d52dfcb2a5db86e346cf51f8fcf2071b8085166, 3fb7394a837740770f0d6b4b30567e60786a63f2 (+8 more)
- EPSS: 0.1% (30-day)
- Action: Update to d8cce4773c2b23d819baf5abedc62f7b430e8745, 8a1fc8d698ac5e5916e3082a0f74450d71f9611f, 6d52dfcb2a5db86e346cf51f8fcf2071b8085166, 3fb7394a837740770f0d6b4b30567e60786a63f2 (+8 more) now
TL;DR
Researchers have published full details and proof-of-concept code for GhostLock. This Linux kernel bug, tracked as CVE-2026-43499, hid in the code for over 15 years. It lets an unprivileged local user reach root and break out of containers.
Why it matters
GhostLock reaches almost every Linux build since 2011. It needs no special privilege, no capabilities, and no user namespaces. Only the PI-futex feature must be on, which many kernels ship. As a result, the flaw threatens desktops, servers, and container hosts alike. Attackers prize kernel bugs that need no foothold at all. In effect, it hands an attacker a clean privilege escalation to root. The container escape is the scary part here. It lets code jump from an isolated workload onto the host. Cloud platforms lean on that isolation to keep tenants apart. So one flaw here can undo careful container defenses. Because working exploit code is now public, the danger is real. Researchers rate the exploit near 97 percent reliable, so it is practical. The VEGA team even earned 92,337 dollars from Google’s kernelCTF.
How the attack works
Priority-inheritance futexes help real-time threads avoid priority inversion. A requeue can move a waiter from one such futex to another. GhostLock hides in that rarely-tested requeue path. At its core, the bug is a stack use-after-free in the rtmutex code. The flaw sits in a cleanup helper named remove_waiter. That helper assumes the running thread owns the lock waiter it clears. However, the requeue path quietly breaks that rule. There, one thread cleans up for another sleeping thread. So the helper clears the wrong task’s state.
It leaves a pointer into a stack frame the kernel already freed. Later, a priority-chain walk follows that stale pointer. From there, the attacker sprays chosen bytes back onto the freed stack. By forging a fake lock structure, they win a limited kernel write. They then rewrite a function-pointer table to hijack control flow. A final step flips a permission bit and yields a root shell. The result is a full local privilege escalation. That same power drives the container escape. The VEGA team documented the whole chain in its research write-up.
Public disclosure and exploitation status
The researchers released the analysis and open-source PoC together. Google’s kernelCTF rules also require winners to publish their exploits. So the code and the technique are now fully public. A planned follow-up will cover the harder Android case. It will tackle stronger defenses like address randomization and flow checks. Even so, no in-the-wild attacks have surfaced yet. The bug does not appear in CISA’s known-exploited catalog. Still, public exploit code shortens the road for future abuse.
Affected versions
GhostLock entered the kernel with a 2011 rtmutex rework. It then sat untouched for about fifteen years. The affected range spans Linux 2.6.39-rc1 through 7.1-rc1. That covers every major distribution without the fix. Ubuntu, Debian, and Red Hat all track the same flaw. The single build requirement is the PI-futex option enabled. Most mainstream kernels turn that option on.
Patch and mitigation
Maintainers fixed GhostLock upstream in Linux 7.1. The patch clears the correct task’s state on the proxy path. Admins should move to a patched or latest LTS kernel now. The first fix also needed a small follow-up for an edge case. Where patches lag, defense-in-depth still helps. Turning on kernel stack randomization makes the reuse step a gamble. A static usermode-helper setting also blocks the root trick shown here. Apply your vendor’s kernel update as soon as it lands.
Support Our Threat Intelligence
If you find our CVE report and cybersecurity news helpful, consider supporting our work.