CWE-805 Buffer Access with Incorrect Length Value, Explained

CWE-805 covers code that reads or writes a buffer in a sequential operation, but uses a length value that is wrong for that buffer. The access then lands outside the memory the buffer owns. When the length is larger than the destination, you get a buffer overflow.

MITRE places this weakness in memory-unsafe languages: C, C++ and assembly. If you ship native code, parse binary formats, or depend on libraries that do, this one is yours.

How it happens

The bug is a mismatch between two numbers: how much room there is, and how much the code thinks it may touch. The wrong length can come from several places.

• A length field read straight from a packet or file header and trusted.
• A length computed from the source when it should come from the destination.
• A length taken from memory that was never initialized.
• Arithmetic on sizes that quietly goes wrong.

MITRE's observed examples show the pattern. CVE-2011-1848 used a packet length field in a calculation and then copied into a fixed-size buffer. CVE-2011-0606 involved a crafted length value in a document reader. CVE-2011-0105 is a chain where the length value came from an uninitialized memory location. CVE-2011-1959 shows a large length value causing a buffer over-read.

Here is the textbook shape in C.

// Vulnerable: len comes from the attacker, buf holds 64 bytes
void handle(const unsigned char *pkt) {
    unsigned char buf[64];
    size_t len = pkt[0];        // up to 255
    memcpy(buf, pkt + 1, len);  // overflows when len > 64
}

Nothing in the code ties len to sizeof buf. The attacker chooses the number.

What an attacker gains

MITRE lists three outcomes. First, reading or modifying memory and executing unauthorized code or commands, since overflows can often be steered into arbitrary code execution, which can undermine other security controls. Second, denial of service: overflows frequently crash the program, and MITRE notes they can also push it into an infinite loop. Third, because code execution sits outside the program's intended security policy, it can subvert whatever other protections the system relies on.

How to find it

MITRE names several detection approaches.

• Automated static analysis. Many tools use data flow analysis or constraint solving to flag lengths that reach a copy unchecked. Static tools do not always account for the environment, so expect to triage.
• Automated dynamic analysis. Fuzzing, stress testing with malformed inputs and fault injection feed diverse inputs to the running product. Crafted length fields are exactly what a fuzzer is good at producing.
• Manual analysis. Useful, but hard to cover fully when the attack surface is large.

A cheap habit helps too: grep for every memcpy, memmove, read and loop that indexes a buffer, and ask where the length came from.

How to fix it

1. Bound the length against the destination, not the source. Clamp or reject before you copy.
2. Choose a safer language where you can. MITRE notes that languages with their own memory management, such as Java and Perl, are not subject to buffer overflows, and that the native code interface of a safe language can still be exposed.
3. Use vetted libraries. MITRE points to safer string handling libraries such as the Safe C String Library and Microsoft's Strsafe.h. It also notes that these are not complete, since many overflows are not about strings.
4. Turn on compiler defenses. Flags such as Visual Studio /GS and the FORTIFY_SOURCE option in GCC, along with stack canaries, detect certain overflows at runtime. This is defense in depth, not a cure. The typical result of a caught overflow is still a crash.
5. Never trust an embedded length. Validate it against the real size of the data actually received.

// Fixed: check against the destination and the bytes actually received
void handle(const unsigned char *pkt, size_t pkt_len) {
    unsigned char buf[64];
    if (pkt_len < 1) return;
    size_t len = pkt[0];
    if (len > sizeof buf || len > pkt_len - 1) return;  // reject
    memcpy(buf, pkt + 1, len);
}

Try it yourself

The demo below walks through a static code scan finding unsafe patterns like the one above.

Click through it at your own pace, or open it full screen.

If a vulnerable parser comes in through a dependency rather than your own code, run the free in-browser dependency scan. It needs no login, your file stays on your machine, and it handles up to 100 dependencies. Reachability analysis then tells you whether your code actually calls the affected function.

Quick check

Sources

• MITRE CWE-805