Inside PinTheft: The New Linux Kernel Double-Free That Puts Arch Users at Immediate Risk

The relentless wave of local privilege escalation (LPE) flaws hitting the Linux kernel over the last month—including Copy Fail, Dirty Frag, and Fragnesia—has just grown by one. Security researchers have disclosed a new LPE vulnerability named PinTheft, along with a working public proof-of-concept (PoC) exploit.

Unlike its recent counterparts, which widely compromised nearly every major Linux distribution, PinTheft features a highly specific set of environmental requirements. However, due to default configuration choices, Arch Linux systems are currently the primary population at risk.

Here is the technical breakdown of the flaw, how the exploit works, and the commands required to secure your environments immediately.

Technical Anatomy: How PinTheft Steals Root

PinTheft targets a severe logic flaw within the kernel’s RDS (Reliable Datagram Sockets) subsystem—specifically, a memory corruption issue inside the RDS zerocopy optimization path (rds_message_zcopy_from_user()).

[Unprivileged User]
│
▼
Triggers RDS Zerocopy Send ──► Pins User Pages One-by-One
│
▼ (Inject Page Fault on Later Page)
Error Path Clears Notifier ──► Drops Already Pinned Pages (First Free)
│
▼
RDS Message Cleanup Runs ──► Scatterlist Count Remains Live ──► Drops Same Pages Again (Double Free)
│
▼
Gradually Steals Reference Counts ──► Controlled Page-Cache Overwrite ──► Patches SUID Binary (Root Shell)

1. The Core Logic Bug: When an application initiates a zerocopy send via RDS, the kernel pins the corresponding user-space memory pages into physical memory one at a time. If a page fault or allocation error occurs midway through this loop, the kernel drops into an error-handling cleanup pathway.
2. The Double-Free Condition: In this error path, the kernel drops the pages it already successfully pinned and clears the zerocopy notifier. However, it fails to clear or decrement the tracking structure (scatterlist entries). When the broader RDS message cleanup routine runs a moment later, it sees those live scatterlist entries and drops the exact same pages a second time.
3. Exploitation via Page Cache Overwrite: By repeatedly triggering this failed zerocopy sequence, an unprivileged local attacker can systematically decrement the reference count of specific kernel pages down to zero (“stealing” memory references). The exploit transitions this double-free state into a controlled page-cache overwrite using io_uring fixed buffers.
4. The SUID Hijack: Just like the mechanics of Copy Fail, the attacker targets a readable SUID-root binary (such as /usr/bin/su) loaded into memory. They inject a 4-byte payload directly into the cached version of the binary in the kernel page cache without altering the file on disk. When the attacker executes the modified command, the kernel processes the malicious page-cache version, yielding an immediate root shell session.

The Catch: Strict Pre-requisites for Exploitation

While the exploit is highly deterministic and lethal, the attack surface is significantly constrained compared to other recent kernel flaws. To successfully achieve root via PinTheft, a target system must meet four strict conditions simultaneously:

1. The RDS Module Must Be Loaded: This is the primary bottleneck. Most enterprise distributions (like Ubuntu, RHEL, Debian, and Fedora) do not compile or load the Reliable Datagram Sockets module by default. Arch Linux does.
2. io_uring Must Be Enabled: The exploit relies on io_uring fixed buffer management to achieve the stable page-cache write.
3. Readable SUID-Root Binary: The attacker needs read permissions on a target binary to pull it into the cache.
4. Architecture Constraint: The publicly released payload is compiled specifically for x86_64 architectures.

Damage Control: Immediate Remediation & Stopgaps

If you are running Arch Linux or a custom upstream kernel with RDS enabled, you need to neutralize this vector immediately.

1. The Direct Fix (Upgrade the Kernel)

The patch has already been merged into upstream sources. The cleanest solution is to update your packages and reboot the system:

# sudo pacman -Syu

2. The Live Stopgap (Disable the RDS Module)

If you operate production servers or CI/CD runners that cannot be rebooted immediately, you can cut the exploit path off at the knees by unloading and blacklisting the RDS module. This requires zero downtime.

Temporarily unload the module from memory:

# sudo rmmod rds

Permanently blacklist the module to prevent automated loading:

# echo “blacklist rds” | sudo tee /etc/modprobe.d/disable-rds.conf

Over to You

With LPE bugs targeting the page cache surfacing almost weekly, how are you hardening your environments? Are you actively restricting unprivileged access to kernel modules or implementing custom seccomp profiles? Let’s talk strategy in the comments below!