GhostLock: CVE-2026-43499

Overview

GhostLock, tracked as CVE-2026-43499, is a local Linux kernel vulnerability in the real-time mutex, or rtmutex, code used by priority-inheritance futexes. A local attacker must already be able to run code on the host. The vulnerable kernel path can then support privilege escalation or cause kernel instability.

A futex, short for fast user-space mutex, lets applications handle an uncontended lock in user space without making a system call. When a thread must wait or wake another thread, the application uses the futex syscall so the kernel can manage the blocked threads. Futex activity is normal on Linux. GhostLock concerns a specific priority-inheritance requeue and rollback path, not ordinary futex use.

Learning Objectives

By the end of this room, you should be able to:

• Explain how incorrect rtmutex waiter cleanup creates stale priority-inheritance state.
• Validate the kernel, package, and configuration conditions used by the lab.
• Compare access before and after a controlled privilege-impact demonstration.
• Correlate process, syscall, and kernel evidence.
• Identify the vendor-supported mitigation.

Threat Scope

This is a local vulnerability. An attacker first needs a shell, a compromised service account, a malicious scheduled task, or another way to execute code on the host. GhostLock may then become the next step in the intrusion.

The documented fault is in remove_waiter(). During proxy-lock rollback from futex_requeue(), the function could operate on current instead of waiter::task. The actual waiter's pi_blocked_on state could remain uncleared, leaving a dangling pointer that later priority-inheritance processing might use.

Lab Target

The attached VM uses Ubuntu 22.04 with the AWS kernel package pinned for this exercise. Canonical currently marks the Ubuntu 22.04 linux-aws and linux-aws-6.8 package families as vulnerable to CVE-2026-43499. The VM also has futex priority inheritance enabled.

The VM starts as the low-privileged analyst user. The practical goal is simple: before exploitation, analyst cannot read /root/ghostlock/root-proof.txt; after the GhostLock workflow, the protected root proof becomes readable.

This before-and-after comparison is the room's impact proof. It keeps the VM usable for the detection work while still showing why the vulnerability matters. The destructive raw kernel trigger is represented with captured evidence so the VM stays stable, and so the detection and mitigation tasks are repeatable.

Start the VM by clicking the Start Lab Machine button above and wait for the split-screen desktop to load. Open a Terminal from the desktop before continuing.

Set up your virtual environment

To successfully complete this room, you'll need to set up your virtual environment. This involves starting the Target Machine, ensuring you're equipped with the necessary tools and access to tackle the challenges ahead.

Lab machine

Status:Off

Start Lab Machine

The practical does not run the destructive public exploit chain. It validates the exposed conditions, replays representative trigger evidence, and uses a clearly disclosed privilege helper to demonstrate the security impact while keeping the VM available for investigation.