Longjmp

How longjmp changes control flow

longjmp is a low-level C control-flow primitive that restores a saved execution point and resumes execution there, skipping the normal unwind path. That makes it powerful for nonlocal error handling, but also easy to misuse because the code between the jump target and the jump source does not run.

The important security property is not the jump itself, but the fact that it can bypass ordinary program structure. When software depends on linear cleanup, validation, or state updates after a failure, a nonlocal jump can leave the process in a partially updated state.

Why it is dangerous in security-sensitive code

In security-relevant software, skipped cleanup is often more than a correctness bug. It can leave locks held, allocations unreleased, sensitive buffers resident in memory, or temporary privilege state in place longer than intended. If a program uses longjmp across code that assumed a normal return, the resulting state mismatch can become a reliability issue or a security issue depending on what was skipped.

This is especially risky when the skipped code would have closed file descriptors, zeroed secrets, released mutexes, or restored invariants that other threads or requests depend on. In those cases, a single nonlocal jump can create deadlocks, resource exhaustion, stale authorization state, or data exposure.

Because the control transfer is abrupt, the safest mental model is that every frame between the jump source and destination may be abandoned without running its cleanup logic. That is why longjmp is a sharp tool in hardened systems code, not a general-purpose error path.

Where the failure modes come from

The main failure mode is violated control-flow assumptions. Code that registers cleanup in automatic destructors, finally-style blocks, or ordinary post-call logic can silently fail to execute if longjmp exits the stack frame. In C, that means developers must explicitly design for nonlocal exits rather than assuming structured unwinding will happen for them.

Another failure mode is interaction with concurrent or stateful code. If a longjmp bypasses unlock, commit, rollback, or reference-count decrement logic, the surrounding subsystem may observe inconsistent state. That inconsistency can cascade into denial of service, memory corruption, or unintended reuse of partially initialized objects.

A final issue is auditability. Nonlocal jumps make execution paths harder to reason about, so review, testing, and static analysis must confirm that every jump target remains safe even when called from deep call stacks.

Safer design patterns and review expectations

Use longjmp only when the program has a deliberate nonlocal-exit design and every intervening frame has been written to tolerate being skipped. In practice, that means keeping resource ownership simple, limiting the scope of sensitive state, and avoiding longjmp across code that depends on mandatory cleanup in the normal return path.

Reviewers should look for functions that acquire locks, secrets, or other scarce resources before a possible jump point, then verify that those resources are released through a path that longjmp cannot bypass. Code that mixes longjmp with concurrency, memory-sensitive operations, or security checks deserves especially careful inspection.

When possible, prefer structured error handling that makes cleanup explicit and local. longjmp is not inherently unsafe, but it becomes hazardous whenever the codebase treats it like an ordinary return.