CWE-835 is a loop whose exit condition cannot be reached. It is an infinite loop. MITRE marks it as not language specific and not technology specific. Network protocol stacks, file parsers, embedded devices and operating system components all show up in the record.
How it happens
The loop expects each pass to make progress, such as consuming bytes. Malformed input breaks that assumption. A zero length, a bad terminator or an unexpected value, and the loop spins.
// Vulnerable: a zero length field means no progress
while (pos < total) {
size_t n = read_len(buf + pos); // attacker sends 0
handle(buf + pos + 4, n);
pos += n; // never advances
}
The record lists several real cases:
- CVE-2025-32399: a library for implementing Profinet devices does not check an input used in a loop condition, allowing an infinite loop through a crafted RPC packet.
- CVE-2022-22224: an operating system does not properly process malformed OSPF TLV identifiers, which can make the process loop.
- CVE-2022-25304: a Python machine communication platform did not account for a malformed packet with a null size, so the receiving function never updated its buffer.
- CVE-2011-1027: an off-by-one error leads to an infinite loop on invalid hex-encoded characters.
What an attacker gains
MITRE lists CPU and memory consumption, amplification, and slow or absent responses. One malformed message can occupy a worker permanently.
How to find it
MITRE lists automated static analysis, which can find some instances through data flow analysis. Fuzzing parsers with malformed lengths and truncated data finds many of the rest. Watch for tests that hang rather than fail.
How to fix it
The record has no formal mitigations. Reliable practices:
- Check that each iteration advances, and fail if it does not.
- Validate lengths and counts before using them.
- Bound loops with a maximum iteration count.
- Set timeouts at the request or task level.
while (pos < total) {
size_t n = read_len(buf + pos);
if (n == 0 || n > total - pos - 4) return ERR_FORMAT;
handle(buf + pos + 4, n);
pos += n + 4;
}
Quick check
What is the simplest guard against infinite loops in parsers?
Require progress. If a pass consumes nothing, stop and return an error.
Can a timeout alone fix it?
It limits damage, but the fix is validating input so the loop always ends.
