More Linux panic – “GhostLock” bug in kernel could have spelled trouble for cloud servers

Elevation of privilege

In the Linux world, a kernel panic is the name given to a software crash that brings down the some or all of the kernel itself, which usually means the system needs to shut down and reboot to bring itself up cleanly again.

Being able to provoke a panic and force a reboot at will gives attackers what’s known as a DoS (denial of service) vulnerability, so that they can take out a server at a time of their choosing, which is surprisingly disruptive, and then, perhaps, wait until the system has started up again to everyone’s apparent relief, before crashing it again, and again, and again.

The way we’ve used the word “panic” in this headline, however, is in a media context – stories that have spread this week about a kernel bug denoted CVE-2026-43499 and nicknamed GhostLock.

This is what’s known as an EoP, an elevation of privilege vulnerability that allows a regular user to promote themselves to the all-powerful root account on Linux.

If you’re a LinkedIn user and you’re not yet following @SolCyber, do so now to keep up with the delightfully useful Amos The Armadillo’s Almanac series. SolCyber’s lovable mascot Amos provides regular, amusing, and easy-to-digest explanations of cybersecurity jargon, from MiTMs and IDSes to DDoSes and RCEs.

Even if you know all the jargon yourself, Amos will help you explain it to colleagues, friends, and family in an unpretentious, unintimidating way.

Getting root and escaping guests

EoP bugs aren’t generally considered as serious as remote code execution (RCE) holes that allow attackers to break in without a password or an account on the system in the first place.

But on shared systems, where several regular-level users might be logged in at the same time, EoP bugs are particularly troublesome, because they typically give other users a chance to snoop around where they don’t belong, including riffling through everyone else’s private files, fiddling with system settings, or installing sneaky system-wide surveillance tools to keep tabs on you even after they’ve logged off.

In extreme cases, EoP bugs may even allow two virtual machines (software computers that are supposed to behave as if they’re isolated on a server of their own) on the same host server to spy on each other, and perhaps for users on a guest server to “escape” and run programs on the host server itself.

As you can imagine, in a cloud service where several different companies run their own virtual guests on the same host system, rogue guest servers that can inject themselves into other guests, or even the host, represent a considerable risk.

Unfortunately, the finders of the CVE-2026-43499 security hole claim that it can be used for user-to-root exploits, for guest-to-guest intrusions, and for guest-to-host escapes.

Along with the fancy name GhostLock, this ensured their bug disclosure article a burst of publicity when they published it earlier this week.

The good news, however, is that although the bug was introduced into the Linux kernel way back in 2011, it sat apparently unnoticed and unexploited until it was responsibly disclosed back in April, and fixed on 2026-04-21.

What the futex?

The bug existed in a part of the Linux kernel with the curious name of futex, which helps with what’s known as thread synchronization.

The name futex is short for fast mutex, where mutex is, in turn, short for mutual exclusion.

Mutual exclusion is the jargon term for the precaution taken by two parts of the same program that might be running at the same time to ensure that they only ever access shared resources (such blocks of memory, log files, or network connections) in a disciplined sequence.

If you’ve ever run a program where occasional lines in its output file end up garbled and mixed up with each other, rather than cleanly written one line at a time, you’re experiencing a situation where the program didn’t properly practice mutual exclusion when writing out its results.

Mutexes are a bit like the traffic lights you often get at each end of a narrow bridge that can only fit vehicles in one direction at a time. The “mutual” part is that they act in careful conjunction so they’re never green at the same time, and the “exclusion” is that they keep out traffic from one end when there is already traffic already proceeding the other way.

The GhostLock bug arose because the Linux kernel included a futex function known as remove_waiter(), intended to be used when one part of a program that was already waiting for a “green light” from a futex was ready to give up, and therefore didn’t need to be in the list any more. (Think of this like a car waiting to cross a narrow bridge that decides to do a U-turn and go another way instead.)

The assumption was presumably that the remove_waiter() code would only ever be triggered by the waiting thread itself, so that the removal process would complete in an orderly fashion, not only cleaning up the data associated with the waiter but also terminating the waiter cleanly.

But the remove_waiter() code, it turned out, could be triggered to free up futex memory for a part of the program that wasn’t actually the intended waiting thread.

This left the system in an unstable state, with a futex memory block freed up and returned to the operating system, yet still available for use by (or for deliberate misuse by) a running thread.

This is a classic use-after-free bug (UAF), and allowed the researchers to manipulate the system so they had an active program thread that was knowingly primed for this use-after-free condition.

They could then deliberately use the wrongly freed-up memory in an sneaky way, such that the program didn’t crash but triggered an elevation of privilege instead.

What to do?

Check the Linux kernel your distro provides (or any kernel you compiled yourself), and ensure it is based on officially-supported kernel source code version dated after the patch, which was committed on 2026-04-21.

As a simple starting point, if your current kernel is from May 2026 or later, and is based on official kernel source code with a version number from May 2026 or later, the patch for this bug should already be part of your system.

Note that if your kernel is numbered 7.1.x, the latest version dubbed stable, you’re safe because the 7.1 series only came out in June 2026 and therefore included the April 2026 fix from its first release.

Be aware that the researchers who wrote this up have now published a working exploit for demonstration and educational purposes.

For all that this might help cybercriminals to abuse this bug on unpatched servers, the published exploit isn’t particularly troublesome, given that more than 90 days have passed since they disclosed the bug, and patched kernel source code has been available for plenty of time already.

Why not ask how SolCyber can help you do cybersecurity in the most human-friendly way? Don’t get stuck behind an ever-expanding convoy of security tools that leave you at the whim of policies and procedures that are dictated by the tools, even though they don’t suit your IT team, your colleagues, or your customers!

More About Duck

Paul Ducklin is a respected expert with more than 30 years of experience as a programmer, reverser, researcher and educator in the cybersecurity industry. Duck, as he is known, is also a globally respected writer, presenter and podcaster with an unmatched knack for explaining even the most complex technical issues in plain English. Read, learn, enjoy!