Concurrency, Race Conditions, TOCTOU and Atomicity — DedSec Project

Security bugs are often temporal rather than purely spatial. This module develops a rigorous model for concurrency, races, check-use gaps, lock ordering, atomicity and reproducible lab analysis.

Learning objectives

By the end of this module you should be able to:

• Explain threads, tasks and interleavings and identify its most important trust boundary, state transition, and evidence source.
• Explain shared mutable state and identify its most important trust boundary, state transition, and evidence source.
• Explain check-then-act races and identify its most important trust boundary, state transition, and evidence source.
• Explain TOCTOU across filesystem and IPC boundaries and identify its most important trust boundary, state transition, and evidence source.
• Explain atomic operations and memory ordering and identify its most important trust boundary, state transition, and evidence source.
• Explain locks, deadlocks and lock granularity and identify its most important trust boundary, state transition, and evidence source.

Deep concepts

1. threads, tasks and interleavings

Concurrent programs permit many valid execution orders even when source code looks sequential. Model shared state and the operations that can overlap; a security invariant must hold for every allowed interleaving, not only the one seen during a normal test run.

2. shared mutable state

Mutable state shared across threads, processes, or services needs an explicit synchronization and ownership model. Record which operations are atomic, which state is protected by a lock or transaction, and whether readers can observe partially updated values.

3. check-then-act races

A check-then-act race appears when a condition is validated and later used after another actor can change the underlying state. Safer designs combine validation and action under one authority boundary or use an operation that fails atomically if the state no longer matches.

4. TOCTOU across filesystems and IPC

Time-of-check/time-of-use problems are especially subtle when paths, handles, IPC messages, or external resources can change between validation and use. Prefer stable handles, descriptor-based operations, immutable identifiers, and server-side revalidation at the point of action.

5. atomic operations and memory ordering

Atomic operations prevent torn updates but do not automatically make a multi-step protocol correct. Memory-ordering rules determine which writes become visible to other threads; document the synchronization relation instead of relying on timing observed on one CPU.

6. locks, deadlocks and granularity

Locks serialize access but introduce ordering and liveness requirements. Define a lock hierarchy, keep critical sections narrow, and test failure/timeout paths so security-sensitive cleanup does not silently disappear when a lock cannot be acquired.

7. idempotency and distributed races

Distributed systems can receive duplicated, delayed, retried, or reordered requests. Idempotency keys, version checks, transactions, and compare-and-swap style updates help keep operations correct when two actors race across service boundaries.

8. deterministic stress and race detectors

Race detectors, schedulers, stress loops, and controlled fault injection make timing bugs easier to reproduce without exploiting real systems. Preserve the seed, build, workload, timing assumptions, and trace so a fix can be regression-tested.

Authorized lab sequence

• Lab 1 — Create a local counter/update race in a toy program and record inconsistent outcomes.

• Lab 2 — Model a safe file-check/file-open example using temporary files you own, then redesign it around safer handles or atomic primitives.

• Lab 3 — Write invariants for a payment-like state machine and test duplicate/reordered events without real transactions.

Knowledge checks

Answer these without looking at the notes:

Next modules

Recommended related modules: 041, 065, 071, 084, 091, 095. From the main menu, choose Search lessons to find related sections across the full guide.