Description

A time-of-check to time-of-use (TOCTOU) race condition in the dynamic loader (ld.so) of the GNU C Library (glibc) versions 2.14 through 2.44 allows a local attacker to escalate privileges. When expanding $ORIGIN in DT_RPATH for setuid/setgid (AT_SECURE) programs, glibc validates the lexically normalized search path against the trusted directories but then opens the raw, un-normalized path. On systems where the Linux fs.protected_hardlinks sysctl is disabled, a local attacker who hard-links such a program into an attacker-controlled directory and wins a race to replace an intermediate path component with a symbolic link can direct the loader outside the trusted directory, causing it to load an attacker-controlled shared object and execute arbitrary code with the elevated privileges of the program. Exploitation requires an installed setuid or setgid binary whose DT_RPATH uses $ORIGIN followed by ".." traversal that normalizes into a trusted directory, and the ability to hard-link that binary and win the race by swapping a path component for a symbolic link. Major Linux-based OS distributions ship with fs.protected_hardlinks enabled by default and mitigate the vulnerability.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.3",
  "pubDate": "2026-09-22T16:18:06.230Z",
  "pubdate": "2026-09-22T16:18:06.230Z",
  "executiveSummary": "This vulnerability is a Time-of-Check to Time-of-Use (TOCTOU) race condition within the GNU C Library (glibc) dynamic loader (ld.so), affecting versions 2.14 through 2.44.\nThe flaw occurs during the expansion of the $ORIGIN token within the DT_RPATH dynamic section for setuid/setgid binaries subject to AT_SECURE protections.\nAn attacker can exploit this condition to achieve local privilege escalation by manipulating the filesystem path resolution during the library loading process.\nExploitation requires the target system to have the fs.protected_hardlinks sysctl disabled, allowing the creation of hard links to privileged binaries.\nThe attacker must successfully win a race condition to replace a component of the directory path with a symbolic link after the loader has performed the security validation check but before it proceeds to open the shared object file.\nSuccessful exploitation allows for the loading of an attacker-supplied shared object into the process space of an elevated binary, resulting in arbitrary code execution with the privileges of the target setuid/setgid program.\nWhile theoretically severe, the reliance on non-default kernel configurations (disabled hard link protection) significantly mitigates the risk on modern, hardened Linux distributions.",
  "technicalDetails": "The vulnerability resides in the glibc dynamic loader, specifically within the logic responsible for processing DT_RPATH search paths when the $ORIGIN token is utilized in secure-execution mode (AT_SECURE).\nRoot Cause: The loader performs a security validation check against the lexically normalized path to ensure that the search directory resides within an authorized, trusted boundary. However, the subsequent system call to open the shared object file uses the raw, un-normalized path. This discrepancy creates a TOCTOU window.\nExploitation Flow: 1. The attacker identifies a setuid/setgid binary that uses an $ORIGIN-based DT_RPATH containing '..' directory traversal sequences which normalize into a trusted directory. 2. The attacker creates a hard link to this target binary within a directory they control. 3. The attacker initiates the execution of the hard-linked binary. 4. The glibc loader checks the path for safety; because it evaluates the lexical normalization, it perceives the path as safe. 5. Before the loader invokes open() or similar filesystem primitives to load the library, the attacker replaces an intermediate directory component in the path with a symbolic link pointing to an attacker-controlled location. 6. The loader follows the now-malicious path, escapes the intended directory, and loads a crafted shared object from an attacker-specified path. 7. The binary executes the malicious code with elevated privileges.\nComponent and Versioning: The vulnerable component is ld.so. The affected versions range from glibc 2.14 through 2.44.\nEnvironmental Requirements: This exploit is contingent upon the absence of Linux kernel protection mechanisms, specifically fs.protected_hardlinks. When this sysctl is set to 1, the kernel restricts the creation of hard links to files that the user does not own or have read/write access to, effectively preventing the attacker from creating the link to the privileged setuid binary necessary to influence the loader's path resolution.\nPost-Exploitation: By forcing the dynamic loader to map an arbitrary shared object into the process, the attacker can execute arbitrary functions (e.g., via constructors or constructor-like attributes) as the setuid process owner. This results in complete local privilege escalation."
}