Hubbry Logo
Time-of-check to time-of-useTime-of-check to time-of-useMain
Open search
Time-of-check to time-of-use
Community hub
Time-of-check to time-of-use
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Time-of-check to time-of-use
Time-of-check to time-of-use
Time-of-check to time-of-use
View on Wikipedia
from Wikipedia

In software development, time-of-check to time-of-use (TOCTOU, TOCTTOU or TOC/TOU) is a class of software bugs caused by a race condition involving the checking of the state of a part of a system (such as a security credential) and the use of the results of that check.

TOCTOU race conditions are common in Unix between operations on the file system,[1] but can occur in other contexts, including local sockets and improper use of database transactions. In the early 1990s, the mail utility of BSD 4.3 UNIX had an exploitable race condition for temporary files because it used the mktemp()[2] function.[3] Early versions of OpenSSH had an exploitable race condition for Unix domain sockets.[4] They remain a problem in modern systems; as of 2019, a TOCTOU race condition in Docker allows root access to the filesystem of the host platform.[5] In the 2023 Pwn2Own competition in Vancouver, a team of hackers were able to compromise the gateway in an updated Tesla Model 3 using this bug.[6] In 2025, a TOCTOU race condition in Amazon Web Services' DNS management system for DynamoDB caused a major outage across the US-EAST-1 region. The incident stemmed from outdated DNS plans being applied after newer ones had already been cleaned up, resulting in the deletion of endpoint IP addresses and widespread service failure.[7]

Examples

[edit]

In Unix, the following C code, when used in a setuid program, has a TOCTOU bug: 

if (access("file", W_OK) != 0) {
    exit(1);
}

fd = open("file", O_WRONLY);
write(fd, buffer, sizeof(buffer));

Here, access is intended to check whether the real user who executed the setuid program would normally be allowed to write the file (i.e., access checks the real userid rather than effective userid).

This race condition is vulnerable to an attack:

Victim Attacker 
if (access("file", W_OK) != 0) {
    exit(1);
}
After the access check, before the open, the attacker replaces file with a symlink to the Unix password file /etc/passwd:
symlink("/etc/passwd", "file");

fd = open("file", O_WRONLY);
write(fd, buffer, sizeof(buffer));
Actually writing over /etc/passwd

In this example, an attacker can exploit the race condition between the access and open to trick the setuid victim into overwriting an entry in the system password database. TOCTOU races can be used for privilege escalation to get administrative access to a machine.

Although this sequence of events requires precise timing, it is possible for an attacker to arrange such conditions without too much difficulty.

The implication is that applications cannot assume the state managed by the operating system (in this case the file system namespace) will not change between system calls.

Reliably timing TOCTOU

[edit]

Exploiting a TOCTOU race condition requires precise timing to ensure that the attacker's operations interleave properly with the victim's. In the example above, the attacker must execute the symlink system call precisely between the access and open. For the most general attack, the attacker must be scheduled for execution after each operation by the victim, also known as "single-stepping" the victim.

In the case of BSD 4.3 mail utility and mktemp(),[2] the attacker can simply keep launching mail utility in one process, and keep guessing the temporary file names and keep making symlinks in another process. The attack can usually succeed in less than one minute.

Techniques for single-stepping a victim program include file system mazes[8] and algorithmic complexity attacks.[9] In both cases, the attacker manipulates the OS state to control scheduling of the victim.

File system mazes force the victim to read a directory entry that is not in the OS cache, and the OS puts the victim to sleep while it is reading the directory from disk. Algorithmic complexity attacks force the victim to spend its entire scheduling quantum inside a single system call traversing the kernel's hash table of cached file names. The attacker creates a very large number of files with names that hash to the same value as the file the victim will look up.

Preventing TOCTOU

[edit]

Despite conceptual simplicity, TOCTOU race conditions are difficult to avoid and eliminate. One general technique is to use error handling instead of pre-checking, under the philosophy of EAFP – "It is easier to ask for forgiveness than permission" – rather than LBYL – "look before you leap". In this case there is no check, and failure of assumptions to hold are signaled by an error being returned.[10]

In the context of file system TOCTOU race conditions, the fundamental challenge is ensuring that the file system cannot be changed between two system calls. In 2004, an impossibility result was published, showing that there was no portable, deterministic technique for avoiding TOCTOU race conditions when using the Unix access and open filesystem calls.[11]

Since this impossibility result, libraries for tracking file descriptors and ensuring correctness have been proposed by researchers.[12]

An alternative solution proposed in the research community is for Unix systems to adopt transactions in the file system or the OS kernel. Transactions provide a concurrency control abstraction for the OS, and can be used to prevent TOCTOU races. While no production Unix kernel has yet adopted transactions, proof-of-concept research prototypes have been developed for Linux, including the Valor file system[13] and the TxOS kernel.[14] Microsoft Windows has added transactions to its NTFS file system,[15] but Microsoft discourages their use, and has indicated that they may be removed in a future version of Windows.[16]

File locking is a common technique for preventing race conditions for a single file, but it does not extend to the file system namespace and other metadata, nor does locking work well with networked filesystems, and cannot prevent TOCTOU race conditions.

For setuid binaries, a possible solution is to use the seteuid() system call to change the effective user and then perform the open() call. Differences in setuid() between operating systems can be problematic.[17]

Real-world consequences

[edit]

TOCTOU vulnerabilities have caused significant outages in large-scale systems. In October 2025, AWS experienced a major disruption due to a race condition in its DNS management system for DynamoDB. The incident involved outdated DNS plans being applied after newer ones had already been cleaned up, leading to the deletion of endpoint IPs and widespread service failure.[18]

See also

[edit]

References

[edit]

Further reading

[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Time-of-check to time-of-use

View on Grokipedia
from Grokipedia
Time-of-check to time-of-use (TOCTOU), also abbreviated as time-of-check time-of-use (TOCTTOU), is a class of software vulnerabilities stemming from race conditions in which a program verifies the state of a —such as a file, location, or shared —at one moment and then relies on that state during a subsequent operation, allowing an attacker to alter the in the intervening period and thereby circumvent intended measures. These vulnerabilities are especially common in environments with asynchronous or multi-threaded access to shared resources, including UNIX-style s where weak semantics enable exploits like attacks in programs that check file permissions before opening them. For instance, a program might use system calls like access() to verify a file's or , followed by open() or fopen() to use it, creating a window for substitution with a malicious file. Historical analysis has identified over 224 vulnerable file call pairs in such systems, with real-world impacts documented in more than 20 CERT advisories between 2000 and 2004, many of which enabled unauthorized root access in applications like sendmail, rpm, vi, and emacs. The exploit likelihood for TOCTOU issues is rated as medium, depending on factors like the duration of the check-to-use gap and the attacker's ability to control timing, though it poses significant risks in privilege-escalation scenarios. Mitigation strategies emphasize avoiding separate check-and-use patterns altogether, employing atomic operations where possible, implementing fine-grained locking mechanisms, or redesigning code to minimize temporal separation, as outlined in secure coding standards like CERT C guideline FIO01-C. Despite ongoing research into detection tools and kernel-level protections, TOCTOU remains a persistent challenge in modern software, including emerging contexts like containerized environments and AI agents.

Overview

Definition

A time-of-check to time-of-use (TOCTOU) , also known as a TOCTTOU , arises when a program verifies the state or condition of a at one point in time but then relies on that verification when accessing or utilizing the at a later point, during which an attacker can modify the 's state to invalidate the earlier check. This temporal discrepancy creates a window of opportunity for exploitation, particularly in systems lacking proper synchronization mechanisms. The consists of three primary components: the check phase, where the program performs a verification such as testing file permissions, , or ; the use phase, where the program acts on the resource based on the assumed validity of the check, such as opening or modifying it; and the critical time gap between these phases, which allows external interference without atomic operations to bridge them. In essence, the check establishes a that the use assumes to hold, but without safeguards, this assumption fails if the state changes intervening. To illustrate the , consider a simple sequence in where a program checks write access to a file before attempting to write to it, without :

if (access("file", W_OK) == 0) { fd = open("file", O_WRONLY); write(fd, buffer, size); close(fd); }

if (access("file", W_OK) == 0) { fd = open("file", O_WRONLY); write(fd, buffer, size); close(fd); }

Here, the access call represents the check phase, while open and write form the use phase; an attacker could replace the file between these steps, potentially leading to unintended actions on a different . TOCTOU differs from general race conditions by specifically emphasizing the security implications of this temporal separation in check-then-use patterns, often in contexts like file systems or shared resources, rather than mere concurrent access without a verification step. It is classified as a subtype of broader concurrency issues, focusing on the exploitability of the verification-use gap in security-critical operations.

Security Implications

Time-of-check to time-of-use (TOCTOU) vulnerabilities create a critical window of exploitability that can lead to severe breaches by allowing attackers to manipulate resources between the verification and utilization phases. This temporal gap enables adversaries to alter the state of checked resources, resulting in unauthorized actions that compromise system integrity. The primary impacts include , where attackers gain elevated access by exploiting the discrepancy to assume unauthorized identities or execute privileged operations; data corruption, through unintended modifications to files or memory; unauthorized access, permitting read or write operations on restricted resources; and denial-of-service, by inducing invalid states that crash applications or exhaust resources. These consequences affect core aspects of security, such as , , , , and . TOCTOU flaws manifest across diverse contexts, including operating systems where kernel-level checks on processes or tokens can be raced; file systems, particularly involving directory traversals or symlink manipulations; network protocols, during state validations in concurrent communications; and multi-threaded applications, where accesses amplify race risks. In these environments, the vulnerability's likelihood of exploit is rated as medium due to the need for precise timing, yet its prevalence in critical software heightens overall exposure. In real-world scenarios, TOCTOU vulnerabilities frequently underpin high-impact exploits in security-critical software, with associated Common Vulnerabilities and Exposures (CVEs) often assigned CVSS v3.1 base scores ranging from 7.0 to 8.5, signifying high to critical severity—for example, CVE-2024-30088 in the Windows kernel scores 7.0, while CVE-2025-55236 in the Windows Graphics Kernel scores 7.8. Such ratings underscore the potential for widespread harm when exploited in production systems. Systemically, TOCTOU defects contribute to broader attack chains by enabling initial footholds that cascade into more devastating compromises, such as zero-day privilege escalations or disruptions in containerized environments akin to risks during image unpacking. For instance, they have been chained in actively exploited zero-days to bypass protections and facilitate lateral movement.

History and Evolution

Origins

The concept of time-of-check to time-of-use (TOCTOU) vulnerabilities traces its roots to early analyses of operating system security flaws in the 1970s, particularly in multi-user systems like and nascent Unix implementations. These systems featured permission models that separated resource validation from access, creating gaps exploitable by concurrent processes. The RISOS project, conducted by the National Bureau of Standards, identified such issues as a form of improper in its 1976 report on computer operating system vulnerabilities, explicitly describing the "time-of-check to time-of-use" problem where a system's validation of a resource state could be invalidated by changes before the resource is used. Similarly, the Protection Analysis (PA) project at the University of Southern California's Information Sciences Institute, in its 1978 final report, classified TOCTOU as a subclass of timing and errors, emphasizing residual inconsistencies in resource allocation and deallocation within environments. By the 1980s, studies on race conditions in early Unix systems further illuminated these gaps, noting how permission checks in file access models allowed attackers to manipulate shared resources between validation and utilization. These precursors laid the groundwork for recognizing TOCTOU as a systemic issue in concurrent, multi-user operating systems, where non-atomic operations exposed security boundaries. The problems were particularly evident in Unix's semantics, which relied on sequential checks without inherent mechanisms to prevent interleaving by malicious or competing processes. The term TOCTOU (or more fully, TOCTTOU) gained prominence in the amid growing awareness of file access races in contexts. A seminal paper by Matt Bishop and Michael Dilger, published in Computing Systems, provided one of the earliest detailed examinations under this nomenclature, analyzing TOCTTOU binding flaws in Unix utilities such as xterm and passwd. The authors modeled detection methods for these races, highlighting their prevalence in real-world exploits like unauthorized password file modifications, and built on prior taxonomies to formalize the vulnerability in modern multi-user deployments. This work marked a key milestone in naming and categorizing the issue, focusing initially on semantics where object identifiers could change post-check. The evolution of TOCTOU awareness was triggered by the proliferation of networked, multi-user systems, which amplified concurrent access risks and underscored the need for robust in permission models. As Unix variants became widespread in academic and commercial settings, vulnerabilities in check-use gaps transitioned from theoretical concerns to practical threats, prompting dedicated research into their mechanics and detection.

Notable Developments

In the , TOCTOU vulnerabilities gained prominence through numerous incidents in Unix-style systems, with the issuing 20 advisories between 2000 and 2004 documenting such flaws in software like and , often involving file access races that enabled . A key example from the emerged in Android's permission system, where naming allowed malicious apps to exploit TOCTOU gaps between permission checks and access, as detailed in a 2014 analysis revealing vulnerabilities in app installation and data sharing processes. Research advancements from 2005 to 2015 focused on modeling and mitigating TOCTOU through systematic analysis, with the 2005 paper "TOCTTOU Vulnerabilities in UNIX-Style File Systems" enumerating 224 vulnerable file system call pairs, analyzing 20 CERT advisories, identifying 26 new vulnerabilities in applications, and proposing kernel-level defenses like atomic calls to prevent races in file operations. Building on this, the 2008 work "TOCTOU, Traps, and " explored formal models for trusted platform modules, highlighting timing attacks in attestation and advocating for synchronized check-use mechanisms in hardware-enforced . The 2010 paper "Modeling and Preventing TOCTTOU Vulnerabilities in Unix-style File Systems" surveyed 20 CERT advisories from 2000-2004, noting 11 enabled unauthorized access, and proposed the EDGI using runtime monitoring with overheads ranging from 0.25% to 47% in benchmarks. In modern , TOCTOU risks have surfaced in resource provisioning, such as a 2024 vulnerability in where attackers exploited races between stack validation and deployment to inject malicious roles, potentially leading to account takeover across six services including S3 manipulation. Similarly, containerized environments have seen notable cases, like the 2020 Kubernetes CVE-2020-8562, a TOCTOU flaw in the server proxy that allowed authorized users to bypass network restrictions and access private control-plane endpoints in versions 1.18.18 to 1.21.0. In Docker ecosystems, a 2020 analysis demonstrated TOCTOU exploitation via mutable image tags, enabling attackers to swap benign containers with malicious ones during pull operations in deployments. Post-2020 updates underscore TOCTOU's ongoing relevance in operating systems, exemplified by CVE-2020-25212 in the kernel's NFS client, a TOCTOU mismatch allowing local attackers to corrupt non-root-owned files via manipulated directory entries, affecting kernels before 5.8.3 and patched through atomic locking enhancements. This incident highlights persistent challenges in file operations, with similar races noted in subsequent audits of kernel subsystems like . In 2025, a critical TOCTOU vulnerability (CVE-2025-22224) was disclosed in vCenter Server, enabling attackers to execute code on the from a . Additionally, products on Windows were affected by a TOCTOU , patched in July 2025.

Examples and Types

File System Vulnerabilities

File system vulnerabilities represent a primary domain for time-of-check to time-of-use (TOCTOU) exploits, where non-atomic operations on files allow attackers to manipulate resources between verification and utilization phases. In systems, these issues arise due to the separation of pathname resolution and file operations, enabling races that compromise security boundaries such as and permissions. Such vulnerabilities often lead to unauthorized data access or modification, with attackers exploiting symbolic links (symlinks) to redirect operations to sensitive targets. A classic example is the symlink attack, in which a privileged program verifies a file's attributes before accessing it, only for an attacker to replace the target with a symlink pointing to a protected file during the intervening period. For instance, in , the program checks a user's mailbox file for validity using stat() before appending new messages; an attacker can swap the mailbox with a symlink to /etc/passwd, allowing the append operation to inject unauthorized entries as , potentially granting elevated privileges. This exploit succeeds because the does not atomically link the check to the use, creating a window for manipulation estimated at microseconds to milliseconds depending on system load. The mechanics of this vulnerability can be illustrated through a step-by-step breakdown in a Unix environment, typically involving stat() for the check and open() for the use:
  1. The program resolves a pathname (e.g., /tmp/target) and calls stat() to verify attributes like ownership or existence, storing the results in a structure.
  2. Between the stat() return and the subsequent open() call, an attacker monitors the process (e.g., via signals or polling) and replaces /tmp/target with a symlink to a sensitive file (e.g., /etc/shadow).
  3. The open() call then follows the symlink, operating on the unintended target with the program's privileges.
Pseudocode demonstrating this vulnerable pattern in C is as follows:

#include <sys/stat.h> #include <fcntl.h> void vulnerable_function(const char *pathname) { struct stat sb; if (stat(pathname, &sb) == -1) { // Handle error return; } if (sb.st_uid != getuid()) { // Check ownership // Deny access return; } // TOCTOU gap here: Attacker can replace pathname with symlink int fd = open(pathname, O_WRONLY); // Opens unintended file // Write to fd as privileged user close(fd); }

#include <sys/stat.h> #include <fcntl.h> void vulnerable_function(const char *pathname) { struct stat sb; if (stat(pathname, &sb) == -1) { // Handle error return; } if (sb.st_uid != getuid()) { // Check ownership // Deny access return; } // TOCTOU gap here: Attacker can replace pathname with symlink int fd = open(pathname, O_WRONLY); // Opens unintended file // Write to fd as privileged user close(fd); }

This sequence, common in utilities like rpm or vi, has been confirmed exploitable with success rates up to 85% under controlled conditions. Variants of these exploits include directory traversal TOCTOU during path resolution, where attackers alter directory components mid-resolution to bypass restrictions. In Unix systems, path traversal involves iterative lookup of directory entries to map a pathname to an inode; if a check (e.g., permission validation on a parent directory) precedes full resolution, an attacker can rename or symlink a directory segment, redirecting the path to unauthorized areas. This requires changing the pathname-to-disk-block mapping between operations, a core weakness in the Unix virtual file system model. Equivalent issues exist in Windows , where TOCTOU races in file handling can lead to information disclosure or . For example, a in attribute processing allows local attackers to exploit gaps between checks and uses, similar to symlink redirection but leveraging reparse points or junctions; CVE-2025-50158 describes such a flaw enabling unauthorized access to sensitive data via non-atomic file operations. Historically, 1990s Unix mail spooler exploits exemplified these risks, often leading to access. In BSD-derived systems like , the binmail program suffered a TOCTOU in appending to spool files: it used lstat() to check a mailbox (e.g., /usr/spool/mail/user) before writing as root, allowing attackers to replace it with a symlink to /etc/passwd and append malicious entries for . Similar flaws in passwd utilities enabled .rhosts creation via symlink races, widespread until patches in the mid-1990s; these cases prompted early CERT advisories and tools for detection.

Network and Process Examples

In network protocols, TOCTOU vulnerabilities arise when a DNS resolver checks the time-to-live (TTL) value of a cached entry to verify its validity but subsequently uses the entry after it has expired due to a . This gap can enable attackers to exploit stale or spoofed records. For example, DNS entries with TTL=0 can trigger TOCTOU in address validation, allowing server-side request forgery (SSRF) attacks where the resolved IP changes between check and use, as seen in CVE-2018-3759 affecting certain gems. In inter-process scenarios, TOCTOU flaws often occur during privilege management in multi-threaded or concurrent applications, where a check on user credentials or state is performed, but another thread or process alters the state before use, leading to incorrect . This stems from non-atomic operations in systems, allowing escalation if sensitive actions rely on the stale check. A contemporary example appears in microservices-based cloud environments, where token validation is susceptible to TOCTOU due to distributed latencies. A gateway service may verify a token's authenticity and expiration upon receipt, but high network delays in cloud infrastructures can allow the token to be forwarded and used in a downstream service after revocation or invalidation. In clusters, without the --service-account-lookup flag enabled, service account tokens are not validated against etcd for existence, potentially allowing use after associated ServiceAccount deletion and enabling unauthorized access. These network and process instances differ from file-based TOCTOU by emphasizing distributed timing across components or over networks, rather than local atomicity failures, which amplifies challenges from variable latencies and concurrent distributed operations.

Memory and Shared Data Examples

TOCTOU vulnerabilities also manifest in and shared data structures, particularly in multi-threaded programs lacking proper . For instance, a thread may check if a shared pointer is valid (non-null) before dereferencing it, but another thread frees the memory in the interim, leading to use-after-free errors that can cause crashes or . This is common in languages like C/C++ without atomic operations, as highlighted in secure coding guidelines. Real-world impacts include buffer overflows in libraries like glibc's malloc implementation, where race conditions between allocation checks and uses enable heap exploitation.

Technical Aspects

Race Condition Mechanics

A time-of-check to time-of-use (TOCTOU) arises in a two-phase model where a program first performs a conditional verification, or "check," to assess the state of a —such as confirming file permissions or —and then executes an unconditional action, or "use," on that assuming the checked state persists. This separation creates an exploitable time gap, known as the delta-t, during which an attacker can alter the resource's state, leading to unintended behavior such as unauthorized access. Several factors enable these races in practice. Concurrency models, including multi-threaded applications, , and hardware interrupts, allow parallel execution that can modify shared resources between the check and use phases. Additionally, non-atomic operations in operating system APIs, such as sequential system calls like access() followed by open() using pathnames rather than file descriptors, fail to guarantee atomicity, permitting binding changes in directories or files. These vulnerabilities are particularly prevalent in Unix-style file systems where weak synchronization primitives exacerbate the issue. The window of vulnerability can be mathematically represented as the time difference between the use and check phases: Δt=tuse−tcheck\Delta t = t_{use} - t_{check} where tcheckt_{check} is the of the verification and tuset_{use} is the of the action; this Δt\Delta t quantifies the interval during which an exploit is feasible, often measured in milliseconds and varying with system load or . Detecting TOCTOU races presents significant challenges due to their non-deterministic nature, which depends on timing, scheduling, and environmental factors like permissions. Stress testing under high concurrency can reveal some instances, but —such as static analysis of pairs or dynamic monitoring of binding intervals—are often required for comprehensive identification, though they remain incomplete per on undecidability. These approaches incur overhead, typically a few percent for dynamic tools, and necessitate knowledge of the runtime environment to distinguish exploitable intervals.

Timing Challenges

Timing challenges in time-of-check to time-of-use (TOCTOU) vulnerabilities arise primarily from the inherent non-determinism of the interval between the check and use operations, often referred to as , which can fluctuate unpredictably across executions. This variability stems from hardware factors such as differences in CPU speeds, cache hierarchies, and handling, which can introduce delays ranging from microseconds for cache misses to longer periods influenced by processor architecture and load. For example, caching effects and during process operations can significantly alter the effective timing window for state changes. Operating system scheduling exacerbates these issues by introducing preemption, I/O wait times, and competition from kernel threads like network time daemons or swappers, potentially extending Δt to seconds under high system load. Environmental factors, including and characteristics such as size or fragmentation, further contribute to this unpredictability, making consistent reproduction of the difficult. In distributed or networked contexts, additional latency from communication delays across devices widens the TOCTOU window, complicating inter-device . Exploiting TOCTOU demands precise timing from attackers to ensure their modifications occur within these narrow windows, typically on the scale, as the success of interleaving operations with the victim process relies on "winning the race" against timing. Variability reduces reliability, with empirical success rates varying widely—for instance, up to 85% in scenarios leveraging predictable scheduling quirks like those in package managers, but dropping to 4-8% in others, such as text editors affected by I/O variability. Attackers may employ techniques such as repeated invocation of calls or manipulation of process priorities to probe and align with these windows, though such methods require deep knowledge and often fail due to the non-deterministic nature of the environment. Analysis and detection of TOCTOU pose significant hurdles because of this non-determinism, rendering vulnerabilities hard to reproduce and identify in practice. Static analysis tools falter as they cannot account for dynamic state changes induced by concurrent attackers or environmental shifts, while dynamic detectors like ThreadSanitizer, which target memory data races using happens-before tracking, often miss TOCTOU involving file systems or external resources and generate false positives in timing-sensitive code due to their overhead, limiting applicability in production environments, and the tools' focus on intra-process races leaves inter-process or kernel-mediated TOCTOU largely undetected.

Prevention Strategies

Atomic Operations

Atomic operations represent a fundamental technique for mitigating time-of-check to time-of-use (TOCTOU) vulnerabilities by executing the check and subsequent use phases as a single, indivisible unit, thereby preventing any intervening state changes that could be exploited by concurrent processes or threads. This approach ensures that the resource's state at the time of verification directly determines its state during utilization, closing the temporal gap inherent in non-atomic sequences. In practice, such operations leverage hardware or system-level primitives that are guaranteed to complete without interruption, making them essential for secure concurrent programming. In systems, atomic file operations exemplify this concept, such as using fcntl() advisory locks to serialize access to files and prevent races during read-modify-write cycles. These locks, applied via file descriptors, allow a to acquire exclusive control over a file , ensuring that checks for or permissions are followed immediately by the intended use without external interference. Similarly, POSIX-compliant APIs like rename(2) provide atomic renaming or replacement of files within the same filesystem, where the operation either succeeds fully or fails without partial effects, thus avoiding TOCTOU exposures in scenarios like secure file updates. For multithreaded environments, compare-and-swap (CAS) instructions offer a lock-free atomic mechanism to update shared variables only if their current value matches an expected one, directly addressing TOCTOU-like races in memory access. In GCC, the __sync_bool_compare_and_swap builtin implements this by atomically comparing the value at a pointer with an expected value and swapping in a new value if they match, returning a boolean indicating success. This primitive underpins many concurrent data structures, ensuring thread-safe modifications without traditional locks. To illustrate, consider a non-atomic file check-use sequence vulnerable to TOCTOU:

if (access("/path/to/file", F_OK) == 0) { // Attacker could replace file between access and open fd = open("/path/to/file", O_RDONLY); // Use fd... }

if (access("/path/to/file", F_OK) == 0) { // Attacker could replace file between access and open fd = open("/path/to/file", O_RDONLY); // Use fd... }

An atomic alternative uses file descriptor-based operations post-initial open, or leverages rename(2) for replacement:

fd = open("/path/to/tempfile", O_WRONLY | O_CREAT | O_EXCL, 0600); // Atomic creation // Write to fd... close(fd); if (rename("/path/to/tempfile", "/path/to/file") == -1) { // Handle failure; original file unchanged }

fd = open("/path/to/tempfile", O_WRONLY | O_CREAT | O_EXCL, 0600); // Atomic creation // Write to fd... close(fd); if (rename("/path/to/tempfile", "/path/to/file") == -1) { // Handle failure; original file unchanged }

In multithreading, a non-atomic update might be:

if (*shared_counter == 5) { *shared_counter = 6; // Race possible here }

if (*shared_counter == 5) { *shared_counter = 6; // Race possible here }

The CAS equivalent ensures atomicity:

if (__sync_bool_compare_and_swap(&shared_counter, 5, 6)) { // Update succeeded only if value was 5 }

if (__sync_bool_compare_and_swap(&shared_counter, 5, 6)) { // Update succeeded only if value was 5 }

Despite their efficacy, atomic operations have limitations that must be considered in TOCTOU prevention. For instance, rename(2) is only atomic when source and destination reside on the same filesystem; cross-filesystem moves require non-atomic copy-and-unlink sequences, reintroducing potential races. Furthermore, in performance-critical paths, atomic primitives like CAS can incur overhead due to hardware-level retries in contended scenarios, potentially degrading throughput compared to coarser-grained locking.

Best Practices and Tools

To mitigate time-of-check to time-of-use (TOCTOU) vulnerabilities, design principles emphasize minimizing the temporal gap between resource checks and uses while adhering to least privilege and models. Developers should avoid binaries where possible, as they amplify risks by granting elevated privileges during vulnerable windows, and instead opt for privilege separation to limit the scope of potential exploits. Capability-based systems, which enforce fine-grained access through unforgeable tokens, reduce TOCTOU exposure by ensuring resources are referenced immutably without relying on transient state checks. In coding practices, validation should occur at the point of use rather than beforehand to eliminate the race window; for file operations, this involves opening files once and performing all subsequent actions via file descriptors instead of pathnames, ensuring atomicity without intermediate checks. For database interactions, employing ACID-compliant transactions with isolation levels like Serializable or Repeatable Read prevents concurrent modifications that mimic TOCTOU by serializing access and locking resources during critical sections. Synchronization mechanisms, such as mutex locks for shared resources or transactional file systems, further bridge check-use gaps in multi-threaded environments. Tools for TOCTOU prevention include static analyzers like , which flags separated check-use patterns in C/C++ code via rule S5847, and , which detects race conditions in privileged programs such as binaries. Runtime detectors like Valgrind's Helgrind identify unsynchronized memory accesses that enable TOCTOU races in threaded applications by tracing lock acquisitions and data conflicts. Modern languages like mitigate risks through built-in concurrency traits (Send and Sync), which enforce thread-safe resource handling and warn against TOCTOU-prone file metadata operations in the standard library. These tools integrate into CI/CD pipelines, such as Jenkins or GitHub Actions, for automated scanning during builds to catch vulnerabilities early. Emerging methods leverage tools like TLA+ to model and prove absence of timing-dependent races in concurrent systems, providing mathematical guarantees against TOCTOU in distributed or kernel-level code. In containerized environments, profiles enforce mandatory access controls that restrict symlink creation and file manipulations, thereby limiting exploitation of TOCTOU races. Recent research as of 2025 has also explored mitigations for TOCTOU in LLM-enabled agents, such as tool-fusing strategies that combine validation and execution in tool calls to prevent races in AI systems.

References

  1. https://cwe.mitre.org/data/definitions/367.html
  2. https://www.usenix.org/legacy/event/fast05/tech/full_papers/wei/wei.pdf
  3. https://nvd.nist.gov/vuln/detail/CVE-2025-23359
  4. https://arxiv.org/abs/2508.17155
  5. https://cwe.mitre.org/data/definitions/362.html
  6. https://nvd.nist.gov/vuln/detail/CVE-2024-30088
  7. https://nvd.nist.gov/vuln/detail/CVE-2025-55236
  8. https://nvd.nist.gov/vuln-metrics/cvss
  9. https://nvd.nist.gov/vuln/detail/CVE-2025-47290
  10. https://gbhackers.com/pwn2own-day-3-zero-day-exploits/
  11. https://cyberpress.org/windows-cloud-files-mini-filter-driver-flaw/
  12. https://nvlpubs.nist.gov/nistpubs/Legacy/IR/nbsir76-1041.pdf
  13. https://csrc.nist.gov/files/pubs/conference/1998/10/08/proceedings-of-the-21st-nissc-1998/final/docs/early-cs-papers/bisb78.pdf
  14. https://www.usenix.org/legacy/publications/compsystems/1996/spr_bishop.pdf
  15. https://www.usenix.org/event/fast05/tech/full_papers/wei/wei.pdf
  16. https://ink.library.smu.edu.sg/context/sis_research/article/3531/viewcontent/PermissionBasedAndroidSecurity_2014.pdf
  17. https://www.cs.dartmouth.edu/~sws/pubs/bdss08-proof.pdf
  18. https://www.sciencedirect.com/science/article/abs/pii/S0167404810000830
  19. https://www.aquasec.com/blog/bucket-monopoly-breaching-aws-accounts-through-shadow-resources/
  20. https://nvd.nist.gov/vuln/detail/CVE-2020-8562
  21. https://www.sysdig.com/blog/toctou-tag-mutability
  22. https://www.truesec.com/hub/blog/cve-2025-22224-critical-vmware-toctou-vulnerability
  23. https://support.eset.com/en/ca8840-eset-customer-advisory-toctou-race-condition-vulnerability-in-eset-products-on-windows-fixed
  24. https://nvd.nist.gov/vuln/detail/CVE-2025-50158
  25. https://seclab.cs.ucdavis.edu/papers/bd96.pdf
  26. https://nvd.nist.gov/vuln/detail/CVE-2018-3759
  27. https://kb.isc.org/docs/aa-00924
  28. https://docs.datadoghq.com/security/default_rules/b5g-dpn-b7g/
  29. https://nob.cs.ucdavis.edu/bishop/papers/1996-compsys/racecond.pdf
  30. https://dl.acm.org/doi/pdf/10.1145/3715014.3722057
  31. https://www.cs.columbia.edu/~junfeng/11fa-e6121/papers/thread-sanitizer.pdf
  32. https://tldp.org/HOWTO/Secure-Programs-HOWTO/avoid-race.html
  33. https://man7.org/linux/man-pages/man2/fcntl.2.html
  34. https://gcc.gnu.org/onlinedocs/gcc/_005f_005fsync-Builtins.html
  35. https://lwn.net/Articles/847973/
  36. https://man7.org/conf/lca2010/writing_secure_privileged_programs.pdf
  37. http://www.cs.ox.ac.uk/toby.murray/papers/AOCS-FCSARSPAWITS-slides.pdf
  38. https://www.sonarsource.com/blog/winning-the-race-against-toctou-vulnerabilities/
  39. https://blog.doyensec.com/2024/07/11/database-race-conditions.html
  40. https://github.com/ros/rospack/issues/103
  41. https://valgrind.org/docs/manual/hg-manual.html
  42. https://doc.rust-lang.org/std/fs/
  43. https://www.sentinelone.com/cybersecurity-101/cloud-security/ci-cd-security-tools/
  44. https://www.alibabacloud.com/blog/formal-verification-tool-tla%252B-an-introduction-from-the-perspective-of-a-programmer_598373
  45. https://kubernetes.io/docs/tutorials/security/apparmor/
  46. https://arxiv.org/pdf/2508.17155
Add your contribution
Related Hubs
User Avatar
No comments yet.