Critical PinTheft Linux flaw lets attackers gain root access

Key Takeaways

• A new Linux Local Privilege Escalation (LPE) flaw, dubbed “PinTheft,” allows attackers to achieve root access.
• The vulnerability, CVE-2024-XXXX (CVE ID not provided in source, placeholder used), resides in the Reliable Datagram Sockets (RDS) zerocopy send path.
• A proof-of-concept (PoC) exploit has been publicly released following the availability of a kernel patch.
• While the exploit requires specific kernel configurations, the RDS module is enabled by default on Arch Linux and can be found in other custom Linux builds.

Cybersecurity researchers have unveiled a critical local privilege escalation (LPE) vulnerability affecting Linux systems, now publicly known as “PinTheft.” A proof-of-concept (PoC) exploit has been released, demonstrating how local attackers can leverage this flaw to gain root access.

The vulnerability, discovered by Aaron Esau of the V12 security team, exploits a double-free bug within the Reliable Datagram Sockets (RDS) zerocopy mechanism. Its public disclosure follows the release of a kernel patch, urging system administrators to update their installations promptly.

PinTheft’s emergence adds to a growing list of recently identified Linux kernel vulnerabilities, underscoring persistent security challenges within complex kernel networking and asynchronous I/O subsystems.

Technical Deep Dive into PinTheft

The core of the PinTheft vulnerability lies within the rds_message_zcopy_from_user() function in the RDS zerocopy send path. During execution, this function pins user pages one by one. A critical flaw arises if a subsequent page fault occurs: the error handling path correctly unpins the pages that were already pinned.

However, a double-free condition is triggered during a later cleanup phase for the RDS message. Because the scatterlist entries and entry count remain active even after the zcopy notifier clears, these same pages are unpinned a second time. This double-free operation allows each failed zerocopy send to effectively steal one reference from the first page, leading to a reference count bug.

Exploitation Methodology

To weaponize this reference count flaw, the PinTheft exploit leverages io_uring. The attack registers an anonymous page as a fixed buffer, assigning it a FOLL_PIN bias of 1024 references. The exploit then systematically depletes these references by initiating 1024 failing RDS zerocopy sends. This process leaves io_uring holding a dangling pointer to a page that has had its references stolen. This unique method of stealing FOLL_PIN references is the origin of the exploit’s name.

The PoC repository details a precise sequence of actions designed to achieve root access while minimizing the risk of permanent system corruption:

• Target Selection: The exploit identifies a readable SUID-root binary, such as /usr/bin/su, /usr/bin/mount, or /usr/bin/passwd.
• Safety Backup: A backup of the target binary is created to allow for manual restoration if needed.
• Page Setup: Two pages are mapped, with the second marked PROT_NONE to ensure a predictable fault during a two-page RDS zcopy send.
• Fixed-Buffer Registration: The target page is pinned using IORING_REGISTER_BUFFERS, adding 1024 references.
• Daemon Child: A child process holds a cloned fixed buffer open, preventing corruption of reclaimed pages by io_buffer_unmap() later in the exploit chain.
• Reference Theft: The exploit executes 1024 failing RDS zerocopy sends, causing the double-drop of the first page during error cleanup, thereby stealing its references.
• Page-Cache Reclaim: The first page of the SUID binary is evicted from the page cache and immediately reallocated, ensuring the stale io_uring fixed-buffer entry now points to a live page cache.
• Dangling Fixed-Buffer Write: An IORING_OP_READ_FIXED operation is used to write a small malicious ELF payload into the compromised page cache, which, upon execution, grants a root shell.

While the underlying exploitation primitive is architecture-independent, the ELF shell payload included in the PoC is specifically compiled for x86_64 environments. Successful exploitation also depends on specific kernel configurations:

• CONFIG_RDS and CONFIG_RDS_TCP must be enabled.
• CONFIG_IO_URING must be active with io_uring_disabled=0.
• The system must permit module autoloading to request TCP transport.

The V12 research team notes that default exposure to PinTheft is somewhat limited across major distributions. Among commonly tested distributions, only Arch Linux has the required RDS kernel module enabled by default. However, custom Linux builds or specific server configurations might still be vulnerable.

Researchers also caution that running the exploit modifies the in-memory page cache of critical SUID binaries. Although a system reboot or cache clearing will revert the memory overwrite, testers on disposable machines must be careful not to leave systems in a state where common programs might unexpectedly execute the malicious payload.

The disclosure of PinTheft aligns with a recent increase in Linux kernel exploit releases. Other recently patched Linux LPEs, such as DirtyDecrypt and DirtyCBC, have also seen PoC exploits released. These vulnerabilities share conceptual similarities with past high-profile root-escalation flaws like Dirty Frag, Fragnesia, and Copy Fail, highlighting an ongoing trend of discovering complex memory-corruption primitives within core Linux systems.

What You Should Do

• Apply Kernel Patches: Immediately update your Linux systems with the latest kernel patches provided by your distribution maintainers.
• Blacklist RDS Modules: If immediate patching is not feasible or if the RDS module is not required, blacklist the vulnerable modules to prevent them from loading. Execute the following command: printf 'install rds /bin/falseninstall rds_tcp /bin/falsen' > /etc/modprobe.d/pintheft.conf
• Remove Active Modules: For running systems, remove active RDS modules using: rmmod rds_tcp rds.
• Review Kernel Configuration: Audit your kernel configuration to ensure that CONFIG_RDS, CONFIG_RDS_TCP, and CONFIG_IO_URING are only enabled if absolutely necessary.

Disclaimer: HackersRadar reports on cybersecurity threats and incidents for informational and awareness purposes only. We do not engage in hacking activities, data exfiltration, or the hosting or distribution of stolen or leaked information. All content is based on publicly available sources.