This month, we have two several Linux vulnerabilities giving root access to local accounts.

Not exotic remote exploits or complicated multi-stage attack chains. Just bugs allowing a local user — or a compromised service account — to become root on a huge range of modern Linux kernels.

In a relatively short period of time, we ended up with multiple privilege escalation vulnerabilities affecting kernels that have been deployed almost everywhere for years. And in real environments, the operational reality is still the same: production servers are rarely rebooted the moment a CVE drops.

So I wanted to better understand three things:

- what these vulnerabilities actually look like on a live system,

- how modern Linux kernel exploitation behaves in practice,

- and which mitigations are realistically useful before a proper kernel update.

I ended up building a small lab to test Dirty Frag and CopyFail.

With “Local Privilege Escalation”, the first reaction I see is “The attacker already has local access, so it’s not that serious.” but in practice, modern infrastructures rely heavily on isolation boundaries: containers, sandboxed processes, service accounts, CI/CD runners.

I myself does not trust every services I run on docker containers or LXC.

In that context, turning a restricted shell into root completely changes the scope of a compromise.

Building the lab

I kept the setup intentionally simple: Proxmox VE, Ubuntu 22.04, vulnerable 6.x kernel.

I mainly wanted to:

- observe system behavior,

- test a few public PoCs,

- and verify which mitigations actually impact exploitation.

First step after booting the VM: checking the kernel version.

uname -r

In my case:

6.5.0-14-generic

Then installing a minimal toolchain:

sudo apt update
sudo apt install build-essential git

I also created a standard non-privileged user:

sudo adduser testuser
su - testuser

At this point, the VM represented a very realistic post-compromise scenario:

- limited shell access,

- no sudo,

- no elevated capabilities.

Exactly the kind of position an attacker might get after exploiting a web application or containerized service.

Dirty Frag / CopyFail: what makes them interesting

The names change, but the underlying themes often stay the same. These vulnerabilities revolve around extremely central Linux kernel mechanisms:

- memory management,

- fragmentation,

- object reuse,

- copy-on-write behavior,

- and page handling.

And that’s precisely what makes them dangerous. Modern Linux kernel exploitation doesn’t really look like old-school stack smashing anymore. In the case of CopyFail, the interesting part is the interaction with copy-on-write logic.

The idea behind copy-on-write is simple: Linux avoids duplicating memory pages until a modification actually happens. Processes initially share the same page, and only receive a private copy when a write occurs.

It has already produced several major vulnerabilities. Dirty COW being the obvious example.

Dirty Frag approaches the problem from a slightly different angle but still lives in the same world: exploiting assumptions around memory reuse and fragmentation.

What becomes obvious when reading the writeups or kernel code is that these vulnerabilities rarely come from one giant catastrophic mistake.

Testing the system behavior

For testing purposes, I reviewed and executed a few public PoCs released after disclosure: to add

Before execution:

id
uid=1000(testuser) gid=1000(testuser)

After compiling and running the PoC:

./exploit

Then eventually:

whoami
root

Temporary mitigations

Obviously, the real fix is patching the kernel.

But in real environments, there is often a delay between CVE disclosure,package availability, internal validation etc

During that gap, the objective becomes reducing exploitability.

One mitigation that proved useful across several recent Linux LPE scenarios is restricting unprivileged user namespaces.

sudo sysctl -w kernel.unprivileged_userns_clone=0
echo "kernel.unprivileged_userns_clone=0" | \
sudo tee /etc/sysctl.d/99-hardening.conf

Verification:

sysctl kernel.unprivileged_userns_clone
kernel.unprivileged_userns_clone = 0

This has operational impact since a lot of modern tooling depends on namespaces:

- rootless containers,

- sandboxing,

- developer tooling,

- and desktop environments.

But during an active vulnerability window, reducing attack surface is often preferable to doing nothing while waiting for maintenance.

Inside my lab, several PoCs immediately lost part of their exploitation path after this change.

The kernel was still technically vulnerable.

But exploitation became significantly less straightforward.

Final thoughts

Testing vulnerabilities like Dirty Frag or CopyFail is a useful reminder of how much modern Linux security depends on mechanisms we usually take for granted.

Dirty Frag and CopyFail probably won’t be the last vulnerabilities of this type.

And honestly, watching a standard low-privileged user become root on a modern Linux kernel is still one of the best reminders that “local access” absolutely does not mean “low impact”.