--- title: 'TOCTOU Races: Timing Vulnerabilities' url: https://www.emergentmind.com/topics/time-of-check-to-time-of-use-toctou-races type: topic --- # TOCTOU Races: Timing Vulnerabilities Searching arXiv for the provided TOCTOU-related papers to ground the article in current literature. Time-of-Check-to-Time-of-Use (TOCTOU) races are timing vulnerabilities in which a system validates some resource or state at one moment and later uses that resource under the assumption that the validated property still holds, even though the state may have changed in the interim. In the supplied literature, this pattern appears across operating systems, remote attestation, in-memory malware detection, browser and desktop GUI agents, AI coding-agent harnesses, private blocklisting, and concurrent resource management. A common formulation is that a check occurs at time \(t_{\text{check}}\) and a use occurs at time \(t_{\text{use}}\); the vulnerability arises when the relevant state differs between those moments, so that the action is performed on stale assumptions [2508.03879][2607.05743][2603.00476][2604.15641][2604.15641]. The surveyed work also makes clear that TOCTOU is not restricted to classic pathname and permission bugs: it recurs wherever validation is separated from action without an enforceable freshness or atomicity guarantee [2607.05743][2508.17155]. ## 1. Definition and formal structure TOCTOU is described as a race condition in which a program or system checks a condition, assumes it remains true, and then acts later after the checked state may already have changed [2508.03879][2603.00476][2604.15641][2604.15641][2508.17155]. The supplied material repeatedly characterizes the defect as a mismatch between validation time and action time. One source states that the system “checks a condition, assumes it is still true, but the condition changes before the system takes action” [2508.17155]. Another states that TOCTOU vulnerabilities “describe inconsistencies that occur when a resource is validated as safe for use but, when actually used later, would have been discovered as unsafe if checked at that time” [2604.15641]. Several papers render this pattern explicitly in timing notation. In the RX-INT threat model, a periodic memory scanner inspects a module at \(t_{\text{check}}\), an attacker alters and executes code at \(t_{\text{attack}}\), restores the original bytes at \(t_{\text{cleanup}}\), and the next scan occurs at \(t_{\text{next}}\); the attack succeeds if \[ t_{\text{check}} < t_{\text{attack}} < t_{\text{cleanup}} < t_{\text{next}} \] because the detector never observes the malicious state [2508.03879]. In agent security, the desired invariant is expressed as \[ \text{check}(s, t_c) \land \text{use}(s, t_u) \Rightarrow \text{state}(s, t_u) = \text{state}(s, t_c) \] and a TOCTOU violation as \[ \text{check}(s, t_c) \land \text{use}(s, t_u) \land \text{state}(s, t_u) \neq \text{state}(s, t_c) \] with \(t_u > t_c\) [2607.05743]. Browser-use agents are modeled similarly by defining page state at observation time \(s_c\), page state at action time \(s_u\), and a target-binding function \(\textsf{Bind}(a,s)\); the vulnerability condition is \[ s_c \neq s_u \;\wedge\; \textsf{Bind}(a, s_c) \neq \textsf{Bind}(a, s_u) \] so that an action selected against one page state resolves to a different target when executed later [2603.00476]. A recurring abstraction in the literature is that TOCTOU is a broader “state-validation problem” rather than merely a low-level bug class [2607.05743]. One survey summarizes the root cause as “authorization is checked once and trusted forever,” and applies that description to permissions, validated files, tool metadata, project trust decisions, and web state [2607.05743]. This suggests that TOCTOU is best understood as a temporal invalidation of a previously accepted predicate. ## 2. Classical systems roots and concurrent resource races The traditional systems understanding of TOCTOU centers on mutable references, especially file-system names, permissions, and path resolution [2603.00476][2201.11764][2508.17155][2603.03141]. The standard pattern is that a process checks a pathname or file property and later performs `open(2)`, `unlink(2)`, or another operation assuming the same object is still being referenced; symlink substitution, directory renaming, or other concurrent changes can redirect the operation to a different object [2603.00476][2603.03141]. The browser-agent work explicitly frames this as “check-then-use” on a mutable reference and notes that the web platform lacks an atomic check-and-act primitive, making the browser analogue structurally similar to OS pathname races [2603.00476]. Concurrent shared-memory systems exhibit an analogous form in “read–destruct races,” where one process reads and then uses a resource while another concurrently overwrites and destructs it [2002.07053]. The paper “Concurrent Reference Counting and Resource Management in Wait-free Constant Time” [2002.07053] treats these races as a specific TOCTOU form and introduces an acquire–retire interface with `acquire`, `release`, `retire`, and `eject` primitives. Its stated guarantee is that if an `acquire` is linked to an `eject`, then all matching `release`s occur before `eject`, so that destruction after `eject` cannot overlap the protected use [2002.07053]. The same work applies this to memory reclamation, reference-counted objects, and ownership-managed objects, precisely to prevent a thread from reading a pointer, file stream, or object and then having another thread free or destroy it before use completes [2002.07053]. The short-race literature further connects TOCTOU to predictive race analysis. “Efficient Dynamic Algorithms to Predict Short Races” [2603.03141] distinguishes semantic TOCTOU races from lower-level data races but notes that TOCTOU patterns often manifest as predictive races over shared state. It defines short races by a span bound \(w\), where a race pair \((e_i,e_j)\) is short if the subtrace from \(e_i\) to \(e_j\) contains at most \(w\) events [2603.03141]. A plausible implication is that TOCTOU bugs are often operationally short because checks and uses are usually close in program order, making short-race detectors a natural fit for prioritizing actionable TOCTOU findings. ## 3. Remote attestation and integrity-checking TOCTOU Remote attestation research treats TOCTOU as a mismatch between when software state is measured and when that measurement is relied upon [2005.03873][2201.11764][2502.07053]. In “On the TOCTOU Problem in Remote Attestation” [2005.03873], the core issue is that conventional remote attestation reveals only the state of the binary at attestation time. Malware can install itself, execute, and erase itself between attestations, or detect an incoming request and restore a clean image before the measurement begins [2005.03873]. That work formalizes a TOCTOU-security game in which a verifier accepts if \(\mathsf{Vrfy}(\sigma_c,c,M,\cdots)=1\) even though there exists \(t_i\) between a reference time \(t_0\) and attestation time \(t_{att}\) such that \(AR(t_i)\neq M\) [2005.03873]. RATA addresses this by storing a protected Last Modification Time \(LMT\) within the attested range \(AR\), updating it whenever executable memory changes, and including it in the attested token [2005.03873]. Two constructions are given: RATAa for devices with real-time clocks and RATAb for devices without them [2005.03873]. In RATAa, the verifier accepts only if \(t_{LMT}