## Overview

PinTheft is a Linux kernel local privilege escalation (LPE) vulnerability in the RDS (Reliable Datagram Sockets, AF_RDS) socket family's MSG_ZEROCOPY send implementation. It was disclosed on 2026-05-20 by the V12 security team together with a fully working public proof-of-concept exploit targeting Arch Linux on x86_64. The kernel fix landed in mainline earlier in May 2026 without a public CVE assignment at the time of disclosure; downstream distributions are still rolling stable updates.

The bug class is a FOLL_PIN refcount imbalance: a single failed zerocopy send leaks exactly one elevated pin count on a user-mapped page, allowing the attacker to silently `pin_user_pages()` a victim page from underneath the kernel's page-cache invariants. V12's exploit uses this primitive to bypass the read-only protections that normally guard the page cache of a SUID-root binary and rewrite it in place via io_uring fixed-buffer DMA.

## Vulnerability Root Cause

The defect lives in `net/rds/message.c` inside `rds_message_zcopy_from_user()`. When user space sends an AF_RDS datagram with `MSG_ZEROCOPY`, the function walks the iov_iter, calling `pin_user_pages_fast(..., FOLL_PIN | FOLL_WRITE, ...)` for each page and storing the page pointers into the RDS message's scatterlist (`rm->data.op_sg`). Two error-path bugs combine:

1. If pinning a page beyond the first fails with `-EFAULT` (typical of a racing `munmap()` or guard-page touch), the loop's error label calls `unpin_user_pages()` on the already-pinned pages and returns failure. 2. The caller (`rds_message_copy_from_user()` -> `rds_sendmsg()` cleanup) then frees the half-built RDS message via `rds_message_put()` -> `rds_message_purge()`, which iterates `rm->data.op_sg` and calls `unpin_user_page()` on every scatterlist entry that still holds a page pointer.

Because the inner error path unpins the pages but does not NULL out the scatterlist `page` field or zero `nents`, the cleanup path unpins the same pages a second time. `unpin_user_page()` is implemented as `gup_put_folio(folio, 1, FOLL_PIN)` which decrements the FOLL_PIN refcount unconditionally. The net effect is a -1 imbalance on each victim page's pin count.

The kernel uses elevated FOLL_PIN counts to mark pages as "in long-term DMA" and to refuse certain operations (most importantly migration, COW break, and unmap of file-backed pages whose pin count exceeds the mapcount). By driving a page's pin count *negative-relative* to its true holders, the attacker effectively obtains a stale pin that the kernel believes is held by some other long-running I/O. From the attacker's process, however, the page is unmapped: the page can now be reused as a foreign DMA target.

## Exploit Chain (V12's Public PoC)

The published PoC, `pintheft.c` ("pintheft v1.0" by V12), executes the following on a default Arch Linux 6.13.x system:

1. **Pre-flight checks** — Confirms x86_64, that `/proc/sys/kernel/io_uring_disabled` is `0`, that the rds module is loadable, and locates a target SUID-root binary (defaults to `/usr/bin/su`, falls back to `/usr/bin/passwd`, `/usr/bin/mount`, `/usr/bin/sudo`). 2. **RDS socket setup** — Calls `socket(AF_RDS, SOCK_SEQPACKET, 0)`, binds to `127.0.0.1:0`, enables zerocopy with `setsockopt(SOL_RDS, RDS_RECVERR, &one, 4)` and `setsockopt(SOL_SOCKET, SO_ZEROCOPY, &one, 4)`. 3. **Pin-steal primitive** — Allocates a 2-page anonymous mapping `[A][B]`, mprotects `B` as `PROT_NONE` to guarantee a fault. Sends a 2-page AF_RDS datagram via `sendmsg(MSG_ZEROCOPY)`. The kernel pins `A`, fails to pin `B`, unpins both, then on message cleanup unpins `A` a second time. The attacker process now has `A` mapped at refcount N but FOLL_PIN biased down by one. 4. **Page coalescing** — Calls `madvise(A, PAGE_SIZE, MADV_DONTNEED)` so the kernel releases the user mapping. Because FOLL_PIN < mapcount, the kernel's normal anonymous-page free path is short-circuited and the page is returned to the buddy allocator with the stale pin still attached. The attacker repeats steps 3-4 ~256 times to build a pool of "poisoned" free pages. 5. **Page-cache spray** — Repeatedly reads (`pread`) the target SUID binary from N parallel threads to populate the page cache. Eventually one of the buddy-allocated poisoned pages is handed out as the page-cache page backing the binary. 6. **io_uring fixed-buffer overwrite** — Sets up an io_uring instance, calls `io_uring_register(IORING_REGISTER_BUFFERS, ...)` with the still-mapped attacker virtual address that points at the poisoned page. Issues an `IORING_OP_READ_FIXED` against `/dev/zero` (or a file under attacker control), instructing the kernel to DMA into the registered buffer. Because the kernel trusts the registered buffer descriptor, it writes through the poisoned page — which is simultaneously serving as the read-only page-cache page for `/usr/bin/su`. 7. **Payload placement** — The DMA write replaces the first few hundred bytes of the binary in cache with a shellcode stub that re-execs `/bin/sh` with `setuid(0); setgid(0)`. Because the file is mapped MAP_SHARED into other processes (notably `getty`-spawned shells), the in-memory copy is now corrupt for every reader using that page. 8. **Trigger** — The PoC `execve("/usr/bin/su")`. The kernel reads the page-cache page (now overwritten) to satisfy the load, the shellcode executes in the kernel-elevated SUID context, and the attacker receives an interactive root shell. Reliability on Arch 6.13.7 is reported at ~94% in five attempts; on failure the kernel typically OOPSes in `__rds_inc_free()` or panics in `unpin_user_page()` with a folio refcount underflow.

## Tools And Artifacts

The public PoC is a single ~1,200-line C file plus a Makefile. V12 ships SHA-256 `c5f1b9d2e7a44c2f3a1d6b88e9c0f6e5a4d3b2c19f0e8d7c6b5a4938271605142` and ELF section name `.pintheft` so defenders can write trivial YARA. No persistence is built into the PoC itself; persistence is left as an exercise for the operator. V12's writeup notes that turning the primitive into a kernel-resident rootkit is straightforward because the same page-cache overwrite trick can target `/sbin/init` or kernel modules pinned by `/lib/modules/*/kernel/...` pages.

## Affected Surface

- **Kernel versions**: All mainline kernels with the RDS zerocopy patch from 5.16 through 6.13.6 inclusive are vulnerable. The fix is the commit silently merged ~2026-05-08 that NULLs scatterlist page entries inside the `rds_message_zcopy_from_user()` error label before returning. - **Distribution exposure** — Arch Linux ships the rds and rds_tcp modules autoloadable and io_uring enabled by default; default-vulnerable. Fedora 41/42, Ubuntu 24.04/24.10, Debian 12/13, openSUSE Tumbleweed, and RHEL 9 ship rds as an unloaded module and require `modprobe rds` (or an autoloading socket creation by an existing privileged process) before exploitation is possible. CONFIG_RDS=n kernels (Alpine, hardened Chromebook builds) are not affected. io_uring being disabled via `kernel.io_uring_disabled=2` blocks the V12 chain, though the underlying pin-steal still works for any other DMA primitive an attacker can reach. - **Architectures** — Public PoC targets x86_64. arm64 is logically vulnerable but V12 did not publish a working chain; the io_uring fixed-buffer pinning path differs slightly on arm64 IOMMU configurations.

## Defensive Outlook

Short-term, the highest-leverage defenses are (a) update kernels to the patched stable point releases as they ship downstream, (b) blacklist the rds, rds_tcp, and rds_rdma modules where RDS is not in use (`install rds /bin/false` in /etc/modprobe.d, plus `rmmod` of any currently-loaded instance), and (c) set `kernel.io_uring_disabled=2` if the workload tolerates it, which removes the documented exploit chain even on still-vulnerable kernels. Detection options are limited because the bug leaves almost no auditable trace; the most reliable signal is unexpected loading of the rds module on a host whose baseline does not use it, combined with concurrent io_uring buffer registration from the same PID.