Race Conditions — Glossary

A flaw that occurs when the outcome of a program depends on the sequence or relative timing of multiple operations accessing a shared resource. When two or more operations race to read or modify the same resource and the result depends on which finishes first, the behaviour of the program becomes unpredictable and potentially exploitable. Race conditions exist wherever a program assumes state will not change between one operation and another — without enforcing that assumption.

The specific race condition pattern where a program checks the state of a resource at one point in time (time of check) and then acts on it at a later point (time of use). If the resource's state changes between the check and the use — and the program does not re-verify — the check's result no longer reflects reality. An attacker who can change the resource inside the race window causes the program to act on stale, falsified information.

The time gap between a program's check of a resource and its use of that resource. This is the window of vulnerability in a TOCTOU attack. Even a race window of microseconds can be reliably exploited by running the attack in a tight loop — thousands of operations per second — until the attacker's change lands inside the window. The attacker only needs to win the race once for the attack to succeed.

An operation that completes entirely in a single, uninterruptible step. No other process or thread can observe or modify the shared resource between the start and end of an atomic operation — there is no gap, and therefore no race window. Making the check-and-use a single atomic operation eliminates the TOCTOU vulnerability entirely: the resource cannot change between check and use because they are the same indivisible step.

A synchronization mechanism that allows only one thread to access a shared resource at a time. Before accessing the resource, a thread acquires the mutex lock. While the lock is held, all other threads attempting to access the same resource are blocked — they must wait. When the first thread finishes, it releases the lock and another thread may acquire it. Mutexes prevent race conditions by ensuring that only one thread can be in the check-and-use sequence at any given moment.

A situation that can arise from improper use of mutexes, where two or more threads each hold a resource the other needs and none can proceed. Thread A holds Lock 1 and waits for Lock 2. Thread B holds Lock 2 and waits for Lock 1. Neither can continue — they are permanently blocked, waiting for each other. Deadlock is not an attack — it is a programming error that can occur when developers add mutex locking without careful design. It is the failure mode that can appear when trying to prevent race conditions with locks.

A race condition in financial or resource-allocation systems where the same resource is allocated or spent more than once because two concurrent requests both pass the same check before either's change is reflected. Classic example: two simultaneous $500 withdrawal requests against a $1,000 account. Both check: balance is $1,000 — both pass. Both execute: $500 each. Result: $1,000 spent from an account that should have allowed only one $500 transaction to proceed. Prevention requires making the balance check and debit a single atomic operation.