PinTheft Linux Flaw Gets Public PoC for Local Root Access

A proof-of-concept exploit is now public for PinTheft, a recently patched Linux local privilege escalation flaw that can let a local attacker gain root access on exposed systems.

The vulnerability sits in the Linux kernel’s Reliable Datagram Sockets zerocopy send path. Researchers at V12 Security said the bug can turn an RDS double-free into a page-cache overwrite through io_uring fixed buffers.

The risk is highest on systems where RDS and RDS_TCP are available, io_uring is enabled, and a local user can run code. Researchers said default exposure appears limited across major distributions, with Arch Linux standing out among the common distributions they tested.

What is PinTheft?

PinTheft is a Linux local privilege escalation exploit discovered by Aaron Esau of the V12 security team. It targets a refcount bug in the RDS zerocopy send path and uses io_uring to make that bug useful for privilege escalation.

The name comes from the exploit’s method. It “steals” FOLL_PIN references until io_uring still holds a stale page pointer that the kernel believes it can reuse.

That stale pointer can then point to the page cache of a SUID-root binary. If the exploit overwrites that cached page with a small payload, running the SUID binary can drop the attacker into a root shell.

PinTheft at a glance

Detail	Information
Vulnerability name	PinTheft
Type	Linux local privilege escalation
Main bug class	RDS zerocopy double-free and reference count handling issue
Exploit primitive	Page-cache overwrite through io_uring fixed buffers
Impact	Root access from a local unprivileged account on exposed systems
PoC status	Public proof-of-concept released
CVE status	No CVE assigned at the time of the latest public reports

How the bug works

RDS supports zerocopy sending, a performance feature that lets the kernel pin user memory pages rather than copying data through a separate buffer.

The bug happens when rds_message_zcopy_from_user() pins pages one by one and a later page faults. The error path drops pages it already pinned, but later cleanup can drop those same pages again because some scatterlist state remains live.

Each failed zerocopy send can remove one reference from the first page. By itself, that sounds like a narrow kernel bookkeeping issue. PinTheft turns it into a root exploit by pairing it with io_uring fixed buffers.

How the PoC turns the bug into root access

The public PoC registers an anonymous page as an io_uring fixed buffer. That gives the page a FOLL_PIN bias of 1,024 references.

The exploit then runs failing RDS zerocopy sends repeatedly until those references are drained. At that point, io_uring still holds a stale pointer, while the kernel can reclaim and reuse the page.

The PoC then tries to reclaim that page as the page cache for a readable SUID-root binary. A fixed-buffer write overwrites the cached binary page in memory with a small ELF payload. When the SUID binary runs, it executes the payload with root privileges.

Exploit requirements

• CONFIG_RDS must be enabled.
• CONFIG_RDS_TCP must be enabled.
• CONFIG_IO_URING must be enabled.
• io_uring must not be disabled through system policy.
• The system must allow the RDS TCP transport to load.
• A readable SUID-root binary must be available.
• The included PoC payload targets x86_64 systems.

V12 noted that the exploitation method is architecture-independent, but the embedded shell ELF in the released PoC is x86_64. That means the public exploit is more limited than the underlying technique.

Why Arch Linux gets the most attention

The attack surface depends heavily on distribution configuration. The key question is not whether a system runs Linux, but whether it can load the RDS modules and use io_uring in the way the exploit needs.

V12 said the required RDS kernel module was enabled by default only on Arch Linux among the common distributions it tested. Other distributions may ship RDS differently, block module autoloading, or omit the required configuration.

Administrators should still check their own systems instead of relying only on distribution names. Custom kernels, hosting environments, appliances, and older system images can differ from stock distribution defaults.

Why the page-cache overwrite matters

PinTheft does not need to change the SUID binary on disk. The PoC overwrites the binary’s in-memory page-cache copy instead.

This matters for both impact and cleanup. A reboot or cache drop can clear the in-memory overwrite, but an exploited system should still be treated seriously because the attacker may already have gained root access.

V12 warns that testing the exploit on disposable systems can leave common SUID programs such as su, mount, or passwd executing the payload from cache until cleanup happens.

What administrators should do now

• Install the latest kernel updates from the distribution maintainer.
• Check whether RDS and RDS_TCP are available and loadable.
• Disable RDS modules if the system does not need them.
• Review whether io_uring is required on exposed multi-user systems.
• Prioritize shared servers, CI runners, hosting systems, and container hosts.
• Reboot or drop caches after any controlled testing on disposable systems.

Systems that do not use RDS can reduce exposure by unloading and blocking the rds and rds_tcp modules. Administrators should test any mitigation in staging first, especially on production servers with specialized workloads.

Mitigation commands

Action	Command
Remove active RDS modules	sudo rmmod rds_tcp rds
Block module loading on reboot	printf ‘install rds /bin/false\ninstall rds_tcp /bin/false\n’ | sudo tee /etc/modprobe.d/pintheft.conf
Check io_uring policy	cat /proc/sys/kernel/io_uring_disabled
Check kernel configuration	grep -E ‘CONFIG_(RDS|RDS_TCP|IO_URING)’ /boot/config-$(uname -r)

If a system needs RDS, the safer long-term fix is to apply a patched kernel. Blocking the module can break legitimate workloads that depend on Reliable Datagram Sockets.

Why shared Linux systems face higher risk

PinTheft requires local code execution, so it does not let a remote attacker compromise a machine by itself. The practical concern is privilege escalation after an attacker already has a low-privilege account or code execution foothold.

That makes the flaw more important for shared systems. Multi-user servers, build machines, CI runners, research clusters, and container hosts can all expose local privilege escalation paths if untrusted users can run code.

Attackers often chain bugs like this with phishing, exposed web apps, stolen credentials, or sandbox escapes. Once they reach a low-privilege shell, a working LPE can turn that access into root.

PinTheft joins a busy Linux LPE wave

The PinTheft PoC arrived during a busy period for Linux kernel privilege escalation research and public exploit releases.

Recent disclosures have included flaws such as Copy Fail, DirtyDecrypt, DirtyCBC, Dirty Frag, and Fragnesia. Several of these issues involve complex kernel memory behavior, page-cache manipulation, or subsystem interactions that make patching and detection difficult.

The pattern is clear: administrators should not wait for every issue to receive a CVE before acting. Kernel update discipline, module hardening, and exposure checks remain critical parts of Linux security.

FAQ