The bug in two sentences
The flaw is a use-after-free in the kernel locking subsystem, on the futex priority-inheritance path — the machinery behind glibc’sPTHREAD_PRIO_INHERIT mutexes. A cleanup step in remove_waiter() clears the wrong thread’s bookkeeping, leaving a live thread pointing at memory that has already been freed.
The freed object sits on the kernel stack rather than the heap, which is where most bugs of this class live. That detail is what makes the exploit so reliable.
The only prerequisite is CONFIG_FUTEX_PI=y, enabled by default in every major distribution. The code was introduced in Linux 2.6.39-rc1 in May 2011 and remained vulnerable through v7.1-rc1 — so effectively every production kernel of the last fifteen years qualifies.
Why this one is different
Local privilege escalations are common and usually rank low on the priority list. Two properties push this one up. The exploit is public and it works. The published full chain reaches root in roughly five seconds at about 97% reliability. That is not a proof of concept requiring a specific kernel build and a favourable wind — it is a working tool. It escapes containers. An unprivileged process inside a container reaches root on the host. If you run untrusted or third-party workloads in containers on a shared node, the isolation you are relying on is not there.Sizing your exposure
The question is not the CVSS score — it is 7.8, and that number tells you little here. The question is: who can execute code on your machine?
Note the pattern: the flaw needs a local foothold. It is not remotely exploitable on its own. But it turns any modest foothold — a compromised web application, a leaked low-privilege account, a hostile dependency in a build — into full control of the machine.
There is no workaround
This is the part that trips people up. Red Hat’s bulletin states it plainly: no runtime kernel parameter and no module can be disabled to address the flaw.CONFIG_FUTEX_PI is compiled into standard builds and cannot be toggled while running.
Unlike a flaw confined to a loadable module, you cannot buy yourself a week with a modprobe blacklist. Patch and reboot, or stay vulnerable.
Patching
Debian, Ubuntu and derivatives
AlmaLinux, Rocky Linux and RHEL
Red Hat’s bulletin covers RHEL 6 through 10, along with OpenShift, OpenStack Platform, RHEL CoreOS, and every product built on the RHEL kernel.
Verify the running kernel
Installing the package is not the same as running it. Confirm after the reboot:On a Kubernetes cluster, a node is only fixed once it has rebooted. Drain, reboot, uncordon, one node at a time — a patched package on a node that has not rebooted still runs the vulnerable kernel.
Timeline
The handling was orderly, which is worth noting: the flaw was reported on 18 April by Nebula Security, fixed upstream two days later in commit3bfdc63936dd, backported on 4 May, and only disclosed publicly on 7 July. Distributions had their patches ready before the details were out.
The exploit followed within a day of disclosure. If your servers have not rebooted since early July, assume the window has been open the whole time.