CVE-2026-43494 / PinTheft: Local Privilege Escalation Risk from Linux RDS and io_uring

Fri, 22 May 2026 15:16:59 +0800

CVE-2026-43494 is a Linux kernel local privilege escalation risk. The related exploitation chain is also known publicly as PinTheft. The key point is not a remote entry point, but whether a low-privilege local user can line up RDS zerocopy, io_uring fixed buffers, a readable SUID-root program, and a suitable kernel version.

One naming detail is worth clarifying first: the Unclecheng-li/poc-lab repository directory is named CVE-2026-43494 PinTheft, while the README title also mentions QVD-2026-27616 - PinTheft. Based on public CVE entries and third-party advisories, CVE-2026-43494 points to a Linux kernel RDS zerocopy issue where op_nents is not reset correctly, leading to a double-free / reference-counting anomaly. QVD-2026-27616 appears more like a Qianxin risk advisory identifier. In real triage, record both identifiers, but treat distribution security advisories and kernel patch status as the source of truth.

What Is the Core Bug?

The issue appears in the zerocopy send path of Linux RDS, Reliable Datagram Sockets. Public descriptions point to these key functions:

1
2

rds_message_zcopy_from_user()
rds_message_purge()

When iov_iter_get_pages2() fails inside rds_message_zcopy_from_user(), pages that have already been pinned can be released by the error path, but the related op_nents state is not cleared correctly. Later, rds_message_purge() may still release the residual entries again. The result is that the same batch of page references can be decremented too many times, creating an exploitable reference-counting error.

Viewed alone, the RDS bug is an error-path memory-management issue inside the kernel. PinTheft becomes dangerous because the exploitation chain connects it with the io_uring fixed-buffer mechanism: io_uring still keeps an old struct page *, while the page itself has already been freed and reallocated for another purpose. The public PoC then steers this state toward overwriting the page cache of a SUID-root program, eventually reaching local privilege escalation.

Why It Is Called PinTheft

io_uring REGISTER_BUFFERS pins user pages. For normal pages, FOLL_PIN is not just a simple reference increment; it raises the page refcount through a larger bias. The public PoC uses the concept of GUP_PIN_COUNTING_BIAS = 1024.

The name PinTheft means the attack chain repeatedly “steals” those pin references through the RDS zerocopy failure path. After the references are drained, io_uring still believes it holds a valid page, but that physical page can now be freed and reused by the page cache.

This class of vulnerability is easy to misread as “directly modifying /usr/bin/su on disk.” A more accurate description is that the exploitation chain tries to overwrite the in-memory page cache. The file itself may not be written back to disk, but when the kernel executes the SUID program, it may fetch instructions from the contaminated page cache and run the attack payload.

The Trigger Conditions Are Not Broad

This is not a vulnerability where “any Linux server can be remotely hit.” Public information indicates that the exploitation chain depends on at least these conditions:

The kernel has CONFIG_RDS and CONFIG_RDS_TCP enabled.
The system has CONFIG_IO_URING enabled, and kernel.io_uring_disabled=0.
The rds / rds_tcp modules are already loaded, or a low-privilege user can trigger autoloading.
A readable SUID-root binary exists locally, such as /usr/bin/su, /usr/bin/passwd, or /usr/bin/pkexec.
The public PoC also depends on the newer IORING_REGISTER_CLONE_BUFFERS API. CloudLinux analysis notes that the public PoC is more aligned with kernel 6.13 and later.

If any one of these links is missing, the public exploitation path breaks. For example, many RHEL-family distributions do not compile RDS by default, older Ubuntu kernels may lack the io_uring clone-buffer API needed by the PoC, and some environments restrict automatic RDS module loading by unprivileged users.

One-Minute Self-Check

First, check the kernel configuration:

1
2

zgrep -E "CONFIG_(RDS|RDS_TCP|IO_URING)" /proc/config.gz 2>/dev/null \
  || grep -E "CONFIG_(RDS|RDS_TCP|IO_URING)" /boot/config-$(uname -r)

Then check whether io_uring is disabled:

`1`	`cat /proc/sys/kernel/io_uring_disabled 2>/dev/null`

Interpret the common values like this:

0: allowed, giving the largest exposure.
1: restricted for unprivileged users; exact behavior depends on kernel version and distribution policy.
2: io_uring disabled.

Check whether the RDS modules exist and can be loaded:

1
2

lsmod | grep -E "^rds|^rds_tcp"
modprobe -n -v rds_tcp 2>&1 | head -3

If CONFIG_RDS is not set, or the system has no rds_tcp module at all, this bug usually cannot be reached. Conversely, if RDS is available, io_uring is not disabled, and the system uses a relatively new general-purpose kernel, continue checking distribution fix status with higher priority.

Which Machines Deserve Priority

Prioritize these environments:

Multi-user Linux hosts, teaching machines, jump hosts, and shared development machines.
Container hosts, especially environments that allow untrusted local users or have a loose container escape surface.
Desktops or servers running newer mainline / rolling kernels, such as Arch-like rolling distributions.
HPC, Oracle RAC, or other scenarios that may genuinely use RDS.
CI workers, build machines, and lab environments that allow unprivileged users to run large amounts of local code.

For an ordinary web server where only controlled service accounts run applications and RDS is not enabled, the practical risk is much lower. But “much lower” does not mean “ignore it”: the typical impact of a kernel local privilege escalation is that an attacker first gains low-privilege access through Web, SSH, CI, containers, or an application bug, then uses the local bug to expand control.

Temporary Mitigation Ideas

The proper fix should still come from the distribution kernel update. Patch status, backported versions, and affected ranges must be checked against advisories from Debian, Ubuntu, RHEL, AlmaLinux, Rocky Linux, SUSE, Arch, cloud vendors, or container base-image providers. Do not judge only by the upstream version number.

While waiting for patches, or when an immediate kernel reboot is not possible, choose temporary measures according to the environment:

# If the business does not depend on RDS, block related module loading
sudo sh -c "printf 'install rds /bin/false\ninstall rds_tcp /bin/false\ninstall rds_rdma /bin/false\n' > /etc/modprobe.d/pintheft.conf"
sudo rmmod rds_tcp 2>/dev/null
sudo rmmod rds_rdma 2>/dev/null
sudo rmmod rds 2>/dev/null

If the business does not depend on io_uring, consider disabling or restricting it:

`1`	`sudo sysctl -w kernel.io_uring_disabled=2`

Persistent configuration needs to be written into the appropriate /etc/sysctl.d/*.conf file. Be careful with this step: modern databases, proxies, runtimes, or high-performance I/O programs may use io_uring. Confirm business dependencies before changing production systems.

How to Verify After Fixing

After upgrading the kernel, do not rely only on package-manager success output. Confirm three things:

1
2
3

uname -a
cat /proc/sys/kernel/io_uring_disabled 2>/dev/null
modprobe -n -v rds_tcp 2>&1 | head -3

If a distribution advisory explicitly says CVE-2026-43494 is fixed, the kernel may still be protected even when uname -r does not look like the newest upstream release, because the stable distribution kernel may have received a backported patch. Conversely, if the kernel comes from a self-built tree, third-party repository, cloud marketplace image, or container host template, continue checking the patch commit and build time.

Io_uring on KnightLi Blog