Skip to content

Time-Of-Check To Time-Of-Use Flaw

Version
v1 · 2026-08-24 · History
Prime #
1241
Origin domain
Computer Science & Software Engineering
Subdomain
security and concurrency → Computer Science & Software Engineering
Aliases
Toctou, Tocttou

Core Idea

A precondition is verified at one instant, the action it authorizes is taken at a later instant, and the relevant state changes in the gap — so the verdict goes stale and the defect lives in the temporal binding between check and use, not in either operation.

How would you explain it like I'm…

Someone Took The Chair

Imagine you check that a chair is empty, then walk across the room to sit down — but while you were walking, someone else sat in it. Your check was right when you made it, but by the time you sat, it was wrong. The problem is the time in between, when things could change.

The Gap In Between

Suppose you look at a parking spot and see it is open, then drive around the block to come park in it. While you were driving, another car took the spot. You were not wrong to look, and you were not wrong to park — the trouble is the gap between looking and parking, when the spot could change. Checking even more carefully when you first looked would not help at all, because the issue is the wait, not how good your look was. The fix is to check again right when you park, or to claim the spot so no one can take it.

Stale-Permission Gap

A Time-Of-Check To Time-Of-Use Flaw is the pattern where a precondition is verified at one instant, the action it authorizes happens at a later instant, and the relevant state changes in between, making the original check false by the time of action. The check itself was sound; the action it allowed is simply no longer authorized when it runs. The defect lives in the gap — not in the check and not in the action, either of which can be individually flawless. The key move is to treat the timing link between verifying and acting as its own thing, separate from whether the check and the action are correct. A sharp consequence: adding stricter checks at the start does nothing to fix this, because the problem is the gap, not the rigor. The cure lies on a scale of binding strength, from re-checking atomically at the moment of use, to leasing with an expiry, down to checking once and hoping.

 

A Time-Of-Check To Time-Of-Use Flaw is the structural pattern in which a precondition is verified at one instant, the action it authorizes is taken at a later instant, and between the two the relevant state changes, making the original verification false at the moment of action. The verification itself was sound; the action it authorized is, by the time it executes, no longer authorized. The defect lives in the gap between check and use — not in either operation in isolation. Three ingredients are load-bearing: a check that consults state S at time t1, an action depending on S at time t2, and the possibility that S changes between t1 and t2. When the gap is non-zero and the state is mutable, the verification's verdict is stale authorization at the moment of action. The essential commitment is to treat the temporal binding between verification and action as a first-class object, separate from the correctness of either; both can be flawless and the system still fails because nothing re-anchored the action's preconditions to execution time. A sharp consequence follows: adding more or stricter checks at t1 does nothing — the issue is the gap, not the rigor. The remedy lives on a continuum of binding strength, from re-checking atomically at use (strongest), through leasing with expiry and re-validating, to checking once and hoping (weakest).

Broad Use

  • Security / concurrency: a process checks a file's ownership, then opens it, and an attacker swaps it for a symlink in between.
  • Aviation: a runway is checked clear and clearance issued, and a vehicle enters before the roll begins.
  • Medicine: pre-operative labs and consent obtained Monday for Wednesday surgery, after coagulation shifts or consent is revoked.
  • Law: a warrant issued on facts true at the time, executed weeks later under changed circumstances.
  • Finance: a credit check approves a loan that disburses a month later, after employment or fraud flags change.
  • Industrial safety: a lockout-tagout verification confirms de-energization, but energization occurs before the worker reaches inside.

Clarity

Re-localizes the defect from "the check missed it" to "the temporal binding was not enforced," and pre-empts the useless response of adding more checks at t1 — the rigor of the check is orthogonal to the staleness of its verdict.

Manages Complexity

Compresses a concurrency or safety review into a three-question scan — what state was relied on, what could mutate it in the gap, what binds the act to state at execution — yielding a sorted family of binding-strength remedies.

Abstract Reasoning

Treats the temporal binding as first-class and arrays remedies on a continuum of binding strength: atomic re-check at use (strongest), lease-with-expiry, then check-once-and-trust (weakest), making the exposure-versus-cost trade explicit.

Knowledge Transfer

  • Surgery: the WHO surgical "time-out" is structurally a database compare-and-swap — rebinding the action to state at the moment of action.
  • Identity / logistics: bind to a stable substrate — a file descriptor over a path, a biometric over a badge, a sealed package over a manifest.
  • Finance: a token TTL, a warrant's shelf life, and a rate-lock expiry are one intervention — leasing a verdict with explicit expiry.

Example

A privileged process runs access(path) at t1 (permitted), but before open(path) at t2 an attacker re-points the path to a system file; hardening access cannot help — the fix is to open first for a file descriptor, then check on the descriptor, an atomic check-and-act on an object that cannot be re-pointed.

Relationships to Other Abstractions

Local relationship map for Time-Of-Check To Time-Of-Use FlawParents appear above the current abstraction, mutual partners to the right, and children below. Node labels state whether each abstraction is prime or domain-specific; colors identify relation types.Time-Of-Check ToTime-Of-Use FlawPRIMEPrime abstraction: Verification — presupposesVerificationPRIMEPrime abstraction: Unverified Precondition — is a kind ofUnverifiedPreconditionPRIME

Current abstraction Time-Of-Check To Time-Of-Use Flaw Prime

Parents (2) — more general patterns this builds on

  • Time-Of-Check To Time-Of-Use Flaw is a kind of Unverified Precondition Prime

    Time-Of-Check To Time-Of-Use Flaw is a specialization of Unverified Precondition, retaining the parent's defining structure while adding the child's specific commitments.

  • Time-Of-Check To Time-Of-Use Flaw presupposes Verification Prime

    Time-Of-Check To Time-Of-Use Flaw presupposes Verification, whose structure must already obtain for the child mechanism to be meaningful or operational.

Hierarchy paths (2) — routes to 2 parentless roots

Not to Be Confused With

  • TOCTOU Flaw is not Verification because verification asks whether a check is correct whereas the TOCTOU flaw stipulates a flawless check whose verdict went stale in the gap — so strengthening verification cannot fix it.
  • TOCTOU Flaw is not Validation because validation asks whether the right thing was checked whereas TOCTOU is indifferent to that: the right property may be checked and the failure still occurs because the state mutated.
  • TOCTOU Flaw is not Calibration because calibration drift is an instrument's accuracy degrading whereas TOCTOU is a correct measurement losing relevance because the measured state itself changed after the reading.