Loop with Unreachable Exit Condition (_Infinite Loop_)

A loop's exit condition can never actually be satisfied under certain inputs, causing the loop to run forever (or until it exhausts some other resource) instead of terminating - a denial-of-service bug where a single crafted input can hang a thread or process indefinitely, distinct from uncontrolled recursion (which grows the call stack) in that this is specifically an iterative loop that never returns.

Confirming this requires input specifically crafted to hit the exact condition that defeats the loop's exit logic, plus observing that the target process actually hangs - risking a genuine denial-of-service against the live target, which a safety-conscious scan avoids triggering deliberately.

Fuzzing with a hang-detection timeout (flagging any input that causes execution to exceed a time budget) run against a non-production instance, and manual/static review of loop exit conditions for cases that cannot be satisfied.

Tip: Static analysis tuned for these specific patterns (format-string misuse, unchecked error paths, unbounded recursion) catches most of this family reliably in code review — the dangerous pattern itself is what's being flagged, independent of any specific runtime input.

Real-World Impact

This family covers code that reaches a function or pattern that's dangerous by construction, regardless of how carefully its specific inputs are validated: format-string functions given a user-influenced format argument, inherently unsafe functions whose entire contract assumes trusted input, unchecked error paths that leave the program in an undefined state, and unbounded recursion or loops that never reach their exit condition.

An externally-controlled format string is a particularly severe example, since format-string functions in C can be coerced into arbitrary memory reads and writes through format specifiers alone, without needing a separate buffer-overflow bug at all. Unchecked exceptional conditions and unreachable-exit-condition loops trend toward denial-of-service rather than code execution, but both share the same underlying pattern: a code path that assumes something will always go as expected, with no handling for the case where it doesn't.

What unifies this category is that the fix isn't input validation in the usual sense — it's recognizing that certain functions or patterns simply shouldn't be reachable with any attacker-influenced input at all, no matter how that input is sanitized.

Prevention and Secure Design

Preventing Loop with Unreachable Exit Condition (Infinite Loop) takes a defense-in-depth approach — no single control below is sufficient alone, but together they close off both the primary path and the most common bypasses.

Never pass user-influenced data as a format string. Use a fixed format string with the user data as an argument (printf("%s", userInput), never printf(userInput)) — this closes off format-string vulnerabilities entirely.

Avoid inherently dangerous functions outright, don't try to use them safely. Where a function's entire contract assumes trusted input (an unsafe deserialization or eval-equivalent function, for instance), replace it with a safe alternative rather than attempting to sanitize input into safety.

Handle every exceptional condition explicitly. An unchecked error return or uncaught exception should be treated as a security-relevant gap, not just a robustness nicety — undefined state after a missed error is where a lot of this family's real-world exploitation begins.

Bound recursion depth and loop iteration explicitly. Any recursive or looping operation whose bound is influenced by external input needs an explicit maximum, independent of what the input claims its size to be.

Static analysis specifically tuned for these patterns. Format-string misuse, unchecked error paths, and unbounded recursion are all patterns static analyzers detect reliably — run one tuned for exactly this family as part of CI.