CWE-1109 Using One Variable for Multiple Purposes: Why It Bites

CWE-1109 is what happens when one variable in a function or block is used to control more than one task or to store more than one kind of data. A variable called tmp that first holds a length, then a pointer, then an error code is the classic shape.

MITRE marks the entry as a quality issue and prohibits using it directly to map vulnerabilities. It is still instructive, because MITRE cites a real vulnerability where this pattern was one link in a chain.

How it happens

Reusing a variable feels economical. It saves a declaration, and in older code it saved stack space or fit a style guide that asked for declarations at the top. The cost is that the name stops telling the truth. After the first reuse, a reader cannot trust what the variable means at a given line without tracing every assignment above it.

What an attacker gains

MITRE lists two consequences: reduced maintainability and increased analytical complexity. The second one says that using the same variable for multiple purposes can make code more difficult for a person to read, potentially hiding other quality issues.

The observed example is CVE-2023-26463. MITRE describes it as a chain in an IPSec VPN product, where the same variable was used for multiple purposes in the same function (CWE-1109), leading to incorrect access control (CWE-284) and an expired pointer dereference (CWE-825). The reuse was not the whole flaw. It was the first link, and the weakness helps explain why the later ones went unnoticed.

How to find it

MITRE lists no detection methods for this entry, but you can look for it directly.

1. Search for variables that are assigned values of different types or meanings in one function.
2. Look for generic names such as tmp, val, ret or x that appear across long functions.
3. In review, ask of each variable: does it mean exactly one thing from its declaration to its last use?
4. Turn on compiler or linter warnings for shadowing and unused assignments, which often surface reuse.

How to fix it

The record has no formal mitigations. The practical fix is plain.

• One variable, one meaning. Declare a new, well named variable for each distinct purpose.
• Name by role. payload_len and error_code say what they hold. tmp says nothing.
• Keep functions short. Reuse tends to appear in long functions where earlier assignments are far from later ones.
• Limit lifetime. Declare variables at first use and let them go out of scope when the job is done.

/* Before: one variable, two jobs */
int n = read_length(pkt);
if (n < 0) return -1;
n = authorize(user, pkt);   /* n now means "auth result" */
use_buffer(pkt, n);         /* bug: n is no longer a length */

/* After: separate roles */
int len = read_length(pkt);
if (len < 0) return -1;
int auth = authorize(user, pkt);
if (auth != 0) return -1;
use_buffer(pkt, len);

The example is illustrative and not taken from the VPN product. It shows how a reused name lets a wrong value reach a later call without any compiler complaint.

Quick check

Sources

• MITRE CWE-1109