PinTheft: How the RDS Zerocopy Bug Lets Attackers Turn Linux Page Cache Into Root Access

What PinTheft Targets in the Linux Kernel

The vulnerability exists in the RDS (Reliable Datagram Sockets) subsystem, a networking protocol used primarily in high‑performance environments such as InfiniBand clusters and some distributed systems.

Specifically, the bug appears in the RDS zerocopy send path, where the kernel attempts to send data directly from user memory without extra buffering. This optimization reduces copies between memory regions but introduces complex memory‑management behavior.

During this process, the kernel function rds_message_zcopy_from_user() pins user pages one at a time to prepare them for transmission. If a later page fault occurs, the error‑handling path attempts to release previously pinned pages—but under certain conditions it incorrectly frees them, producing a double‑free or corrupted reference count.

This memory‑management flaw creates the foundation for a privilege‑escalation exploit.

How the PinTheft Exploit Works (High‑Level)

Researchers demonstrated that the RDS bug can be chained with modern Linux I/O features to turn a memory‑management error into a reliable privilege‑escalation primitive.

1. Triggering the RDS Zerocopy Double‑Free

An attacker with local access triggers the vulnerable RDS zerocopy path. When a page fault occurs during page pinning, the cleanup logic incorrectly releases pages that should still be referenced, leaving the kernel with an inconsistent state or freed pages that may still be referenced elsewhere.

2. Reclaiming Freed Pages With io_uring Fixed Buffers

The exploit then uses io_uring fixed buffers, a feature allowing applications to register memory buffers for high‑performance asynchronous I/O operations.

By carefully manipulating these buffers, the attacker can reallocate the previously freed physical pages in a controlled way, effectively gaining influence over the memory locations involved in the RDS bug.

3. Turning Memory Corruption Into a Page‑Cache Overwrite

Because the corrupted pages may correspond to page‑cache memory—the kernel’s in‑memory cache of file data—the attacker can convert the memory corruption into a page‑cache overwrite primitive.

This means the attacker can change what the kernel serves as file contents without actually modifying the file on disk.

4. Modifying a SUID‑Root Binary in Cache

The exploit chain reportedly targets the cached contents of a SUID‑root executable. When the kernel serves the executable from the modified page cache, it effectively runs the attacker‑modified code while still honoring the file’s root privileges.

Executing the manipulated binary then grants the attacker root access on the system.

Which Systems Are Most Affected

The vulnerability exists in Linux kernels containing the flawed RDS zerocopy implementation, but the real‑world exposure depends heavily on system configuration.

Arch Linux Systems

Security reports highlight Arch Linux as a particularly exposed environment because:

• A working proof‑of‑concept exploit was demonstrated on Arch systems.
• The RDS module may be available depending on kernel configuration.

This combination made Arch installations an early focus for testing and demonstration of the exploit.

Systems With the RDS Module Enabled

Any Linux distribution could theoretically be affected if:

• The vulnerable kernel version is installed.
• The RDS kernel module is available or loaded.

However, many enterprise distributions do not enable or load the module by default.

Default Enterprise Configurations

Reports suggest that standard installations of Ubuntu, Debian, RHEL, and AlmaLinux may be less exposed because the RDS module is typically not enabled in default setups. However, administrators should verify their specific kernel configuration rather than relying on assumptions.

CloudLinux Platforms

CloudLinux reported testing the public proof‑of‑concept across multiple platform versions and stated that their systems were not affected.

Conditions Required for Exploitation

Successful exploitation generally requires several conditions:

• The attacker must have local code execution as an unprivileged user.
• The system must run a vulnerable Linux kernel containing the RDS zerocopy bug.
• The RDS module must be available or loadable.
• io_uring must be usable by unprivileged users, since the exploit uses fixed buffers to reclaim freed pages.
• A SUID‑root binary or similar privileged executable must be present so the page‑cache overwrite can trigger privilege escalation.

Without this combination of factors, the exploit chain becomes significantly harder—or impossible—to execute.

Mitigations and Security Recommendations

Administrators can significantly reduce risk by applying several defensive steps.

Apply Kernel Patches

Kernel maintainers released fixes for the vulnerable RDS code path. Installing the latest kernel update from your distribution vendor is the primary mitigation.

Because kernel updates require a restart to take effect, systems must be rebooted after patching.

Disable the RDS Module if Unused

If your infrastructure does not rely on RDS networking, you can reduce exposure by preventing the module from loading.

Common approaches include:

• Blacklisting the rds module
• Removing it from auto‑load configurations

Restrict Unprivileged io_uring Usage

Since the exploit chain relies on io_uring fixed buffers, restricting or disabling unprivileged access to io_uring can reduce attack surface where feasible.

Audit SUID‑Root Binaries

The final stage of the exploit targets SUID executables, so reviewing unnecessary SUID binaries and removing the SUID bit where possible reduces potential privilege‑escalation targets.

Limit Local Access on Shared Systems

Because PinTheft requires local code execution, systems that allow multiple users—such as CI runners, shared hosting servers, or development machines—should be prioritized for patching and hardening.

The Bigger Security Lesson

PinTheft illustrates how modern kernel exploits often rely on chaining multiple advanced subsystems—in this case RDS networking internals and the io_uring asynchronous I/O framework—to convert subtle memory bugs into powerful privilege‑escalation techniques.

Even relatively obscure kernel modules can become high‑impact attack surfaces when combined with newer performance features. Keeping kernels patched and minimizing unnecessary modules remains one of the most effective defenses against this class of vulnerability.