"PinTheft is a Linux local privilege escalation exploit for an RDS zerocopy double-free that can be turned into a page-cache overwrite through io_uring fixed buffers," V12 said in a Tuesday advisory.
V12 security team's disclosure and the public proof-of-concept
The V12 security team published details and a proof-of-concept (PoC) exploit for a recently patched Linux kernel privilege escalation vulnerability that the researchers named PinTheft. The advisory and PoC show a local attacker can gain root privileges on affected systems; the flaw is in the Linux kernel's Reliable Datagram Sockets (RDS) code. The issue is not yet tracked by a CVE identifier, the researchers said.
How the bug works: an RDS zerocopy double-free and io_uring interaction
V12 described the underlying fault as a double-free in the RDS zerocopy send path. In their words: "The bug lived in the RDS zerocopy send path. rds_message_zcopy_from_user() pins user pages one at a time. If a later page faults, the error path drops the pages it already pinned, and later RDS message cleanup drops them again because the scatterlist entries and entry count remain live after the zcopy notifier is cleared. Each failed zerocopy send can steal one reference from the first page."
The PoC exploits that condition to steal FOLL_PIN references until io_uring—Linux's asynchronous I/O API—remains holding a stolen page pointer. V12's exploit chain then converts that condition into a page-cache overwrite and, ultimately, a root shell.
Preconditions and a narrow attack surface (Arch Linux focus)
PinTheft is not a universal, drop-in threat for all Linux installations. V12 and the published PoC require several specific conditions for successful exploitation: the RDS kernel module must be loaded; the io_uring API must be enabled on the target system; there must be a readable SUID-root binary available; and the exploit's payload requires x86_64 support.
Those constraints significantly reduce the practical attack surface. V12 noted that, among the "common distributions" they tested, the RDS kernel module is enabled by default only on Arch Linux, writing: "Sadly, the RDS kernel module this requires is only default on Arch Linux among the common distributions we tested." The combination of dependencies means most systems will not be vulnerable unless they meet each prerequisite.
Mitigation steps and patch guidance
Linux users on affected distributions were advised to install the latest kernel updates as soon as possible. For environments that cannot immediately apply updates, V12 published a short mitigation that removes and blocks the RDS modules:
- rmmod rds_tcp rds
- printf 'install rds /bin/false\ninstall rds_tcp /bin/false\n' > /etc/modprobe.d/pintheft.conf
Those commands remove the loaded RDS modules and write a modprobe configuration preventing them from being loaded again, which blocks the exploit path that V12 demonstrated.
Context: a string of recent Linux local privilege escalation disclosures and CISA action
PinTheft arrives amid a sequence of disclosed Linux local privilege escalation (LPE) vulnerabilities. Over recent weeks, researchers released PoC exploits for another recently patched LPE tracked as DirtyDecrypt and DirtyCBC; V12 characterized those as belonging to the same vulnerability class as other recent issues including Dirty Frag, Fragnesia, and Copy Fail.
Security observers reported that threat actors have started actively exploiting Copy Fail in attacks. The Cybersecurity and Infrastructure Security Agency (CISA) added Copy Fail to its list of flaws exploited in attacks on May 1 and ordered government agencies to secure their Linux systems within two weeks. Separately, Linux distributions rolled out patches last month for a decade-old privilege escalation in the PackageKit daemon dubbed Pack2TheRoot.
What this means for Arch Linux users, system administrators, and defenders
- Arch Linux users: because the RDS module is enabled by default on Arch Linux among the distributions V12 tested, users and maintainers should prioritize kernel updates or apply the module-removal mitigation until patches are installed.
- System administrators and security teams: confirm whether RDS and io_uring are enabled on hosts, verify the presence of readable SUID-root binaries that could be abused, and apply patches or block the RDS modules where immediate patching is not possible.
- Defenders and incident responders: the public availability of a PoC means exploitation is now easier to test by defenders—and by attackers—so detection and patching should take precedence.
The technical details and a working PoC make PinTheft a concrete demonstration of how a specific kernel path, when combined with io_uring and certain system configurations, can be escalated to full root control. For systems that meet those precise conditions, the choice is straightforward: install the kernel updates issued earlier this month or apply the provided module-blocking mitigation until patches are deployed.
