CWE-670 describes a control flow path that does not match the algorithm it is supposed to implement, so the behavior is incorrect any time that path is taken. It matters to any team shipping logic that guards something: checks, loops, error handling and state machines.
How it happens
MITRE draws a useful contrast. Most weaknesses are cases where code usually behaves correctly except when an attacker manipulates it. This one is different: the code segment is always incorrect with respect to its intended algorithm.
MITRE's example is a C programmer who means to put several statements in one block and leaves out the enclosing braces (CWE-483). Only the first statement is guarded by the condition, and the logic is wrong every time.
/* Vulnerable: only the first line is inside the if */
if (!authorized)
log_denied(user);
return ACCESS_DENIED; /* always runs, even when authorized */
In that fragment, a legitimate user is denied every time. Reverse the intent and the same mistake can grant access to everyone. Related patterns include a switch statement missing a break, a condition with the wrong operator, or an error branch that does the wrong thing.
The record's example CVE is CVE-2021-3011: a virtual interrupt controller in a virtualization product allows a crash of the host by writing a certain invalid value to a register, which triggers a fatal error instead of returning an error code. The error path was implemented in a way that was wrong whenever it was taken, and an attacker could take it.
What an attacker gains
MITRE lists the effect as "Other", with the ability to alter execution logic. Because the path is always wrong, an attacker only needs to reach it. The example above went from an invalid register write to a host crash.
How to find it
The record lists no detection methods. This class usually shows up in tests and reviews rather than in attacks.
- Write tests for every branch, including error branches and rarely used ones.
- Test with invalid input on purpose, and confirm each failure returns an error instead of crashing.
- Compile with all warnings on. Many compilers flag misleading indentation and fall-through.
- Use a formatter and enforce braces on every block through a lint rule.
- In review, read each condition and ask what the code does on the true side and on the false side.
How to fix it
MITRE lists no formal mitigations on this entry. The practical guidance follows from the description.
- Always use braces, even for one statement.
- Return errors from error paths. Do not abort or assert on input that an outside party can supply.
- Cover each branch with a test that checks the outcome.
- Keep conditions simple, and split complex ones into named parts.
/* Safer */
if (!authorized) {
log_denied(user);
return ACCESS_DENIED;
}
Quick check
How is this different from most weaknesses?
Most only misbehave when someone manipulates the code. This one is wrong every time the path runs.
What should happen on invalid input from a guest or device?
An error is returned and the system keeps running. The record's CVE shows a fatal error instead, which let a guest crash the host.
