The TOCTOU Pattern
TOCTOU (Time-of-Check/Time-of-Use) is the core race condition pattern. The program's check and use are two separate steps — and the gap between them is the vulnerability.
Program checks the state of a shared resource. "Does this file have the right permissions? Yes. Does this account have enough balance? Yes." The check returns a result that the program will use to decide whether to proceed.
The program's next instruction is the use — but before it executes, control may pass to another thread, or time elapses during processing. The resource is not locked. The state that was checked can still change.
The attacker (or another thread) modifies the resource during the window. The file is replaced with a symlink. The balance is spent by a concurrent transaction. The permission variable is changed. The state is now different from what was checked.
The program uses the resource — but the resource is no longer what it checked. It acts on the changed state, producing the attacker's desired outcome. Privilege escalation, double-spend, or write to a protected file.
Why the Race Window Is Exploitable
A common misconception is that the race window is too small to exploit. In practice, even a microsecond gap can be reliably targeted.
The Window Doesn't Need to Be Large
Even a race window of microseconds is exploitable. Modern computers execute billions of instructions per second. An attacker script running in a tight loop can attempt thousands of modifications per second. The attacker only needs to win once — and with enough attempts per second, even a tiny window becomes reliably hittable. This is why "the timing is too tight" is not a valid defense against TOCTOU.
Automation Makes It Reliable
An attacker doesn't manually time the attack. They write two concurrent processes: one runs the vulnerable program's trigger repeatedly, and the other replaces the resource repeatedly in a loop. These two loops run simultaneously. Eventually — often within seconds — one replacement lands in the window. Once is all it takes.
The Attack Scales
A race condition vulnerability in widely deployed software can be targeted at scale. Once an attacker identifies a repeatable TOCTOU window in an operating system or application, the exploit can be scripted and run against every affected installation. The difficulty of winning the race once does not limit the number of targets the attacker can run the script against.
Prevention Techniques Comparison
Not all prevention techniques are equally effective. Understanding what each technique does — and its limits — is essential.
| Technique | How It Works | Eliminates Race Window? |
|---|---|---|
| Atomic Operation | Check and use are merged into a single indivisible operation. No other thread can observe or modify the resource between check and use. | Yes — completely |
| Mutex Lock | A lock is acquired before the check and released after the use. No other thread can enter the check-use sequence while the lock is held. | Yes — completely, if used correctly |
| Re-verify at Use Time | Instead of trusting the earlier check, the program checks again immediately before using the resource. | Reduces — but still has a tiny window between re-check and use |
| Larger Race Window | Doing more work between check and use. | No — makes it worse, not better |
Deadlock — The Risk of Over-Locking
Mutexes prevent race conditions but introduce the risk of deadlock. Deadlock occurs when Thread A holds Lock 1 and waits for Lock 2, while Thread B holds Lock 2 and waits for Lock 1. Neither can proceed — both are permanently blocked. Deadlock does not cause a security breach directly; it causes a denial of service — the threads hang forever, and the system or service stops functioning.
Developers must design mutex usage carefully to avoid deadlock: always acquire locks in the same order across all threads, release locks promptly, and use lock timeouts. A program that hangs due to deadlock may be just as harmful to availability as one that crashes.