Heap Buffer Overflow in opkit_compile.c: How Unchecked memcpy Calls Enable Arbitrary Code Execution

Severity: 🔴 Critical | CVE: V-001 | File: src/opkit_compile.c | Fixed In: PR — "fix: remove unsafe exec() in opkit_compile.c"

Introduction

Memory safety vulnerabilities are among the oldest and most dangerous classes of security bugs in software. Despite decades of awareness, tools, and best practices, they continue to appear in production codebases — sometimes in the most performance-critical parts of a system, where developers are optimizing for speed and may inadvertently skip a bounds check.

This post details a critical heap buffer overflow discovered in src/opkit_compile.c, a C source file responsible for compilation logic. Multiple memcpy calls were copying user-controlled data — strings and filenames derived from PHP source files — into heap-allocated buffers without first verifying that the destination buffer was large enough to hold the incoming data.

If you write C or C++, work on compilers or interpreters, or simply care about the security of software infrastructure, this one is worth understanding deeply.

The Vulnerability Explained

What Is a Heap Buffer Overflow?

A heap buffer overflow occurs when a program writes more data into a heap-allocated memory region than that region can hold. Unlike stack overflows (which are often caught by modern stack canaries and ASLR), heap overflows can be notoriously difficult to detect at runtime — and equally dangerous.

When you overflow a heap buffer, you don't just corrupt the data in that buffer. You potentially overwrite:

• Adjacent heap metadata — the bookkeeping structures malloc/free use to track allocations
• Adjacent data buffers — corrupting other live objects in memory
• Function pointers — if a vtable or callback pointer lives nearby on the heap, an attacker can redirect execution flow

The Vulnerable Code

The vulnerability manifested in at least four distinct locations within opkit_compile.c:

Location 1 — Line 154:

// VULNERABLE: No verification that new_str is large enough to hold 'len' bytes
char *new_str = emalloc(some_size);
memcpy(new_str, str, len);

Here, new_str is allocated with some_size bytes, but len — derived from user-controlled PHP source input — is copied without confirming that some_size >= len. If len > some_size, the memcpy writes past the end of the allocation.

Locations 2, 3, 4 — Lines 2091, 2096, 2104:

// VULNERABLE: Filename buffer allocated using ZSTR_LEN(rel_path)+1,
// but 'len' used in memcpy is computed separately and may differ
char *filename_buf = emalloc(ZSTR_LEN(rel_path) + 1);
memcpy(filename_buf, src, len);  // 'len' may exceed ZSTR_LEN(rel_path)+1

In these cases, filename buffers were sized based on ZSTR_LEN(rel_path) + 1 (the length of a relative path string plus a null terminator), but the actual number of bytes copied was controlled by a separately computed len variable. If the two values diverged — which they could, given user-supplied input — the result was a heap overflow.

How Could This Be Exploited?

An attacker who can influence the PHP source files being compiled (e.g., through a file upload feature, a CI/CD pipeline processing untrusted code, or a shared hosting environment) could craft malicious input that triggers the overflow.

Step-by-Step Attack Scenario

1. Attacker crafts a PHP file with a specially constructed string or filename whose computed len exceeds the allocated buffer size.
2. The compiler processes the file, calling the vulnerable memcpy with a length larger than the destination buffer.
3. Heap metadata or a function pointer is overwritten with attacker-controlled bytes.
4. On the next heap operation or function call, the corrupted pointer is dereferenced — redirecting execution to attacker-controlled code.
5. Arbitrary code executes in the context of the compiler process, potentially with elevated privileges.

This is a classic heap exploitation primitive. Modern exploit mitigations (ASLR, PIE, heap hardening) raise the bar, but sophisticated attackers have well-documented techniques to bypass them — particularly when they control the input format and can trigger the overflow reliably.

Real-World Impact

• Remote Code Execution (RCE): In environments where the compiler processes untrusted input (e.g., online code editors, build servers, PaaS platforms), this could lead to full server compromise.
• Privilege Escalation: If the compiler runs with elevated privileges (common in build pipelines), an attacker could escalate from a low-privilege file upload to system-level access.
• Supply Chain Attack: A compromised build system could inject malicious code into compiled artifacts, affecting downstream users.
• Data Exfiltration: Even without full RCE, heap corruption can be used to leak sensitive memory contents.

The Fix

What Changed

The fix ensures that before any memcpy call, the destination buffer is verified to be large enough to hold the data being copied. This is achieved through a combination of:

1. Consistent size tracking — ensuring the allocated size and the copy length are derived from the same source, or explicitly compared before use.
2. Bounds assertions — adding explicit checks that abort or error gracefully if sizes don't match, rather than silently overflowing.

Fixed pattern — Line 154:

// SAFE: Allocate exactly 'len' bytes, ensuring the buffer matches the copy size
char *new_str = emalloc(len);
if (new_str == NULL) {
    // Handle allocation failure
    return NULL;
}
memcpy(new_str, str, len);

Fixed pattern — Lines 2091–2104:

// SAFE: Use the same length value for both allocation and copy
size_t filename_len = ZSTR_LEN(rel_path) + 1;
char *filename_buf = emalloc(filename_len);
if (filename_buf == NULL) {
    return NULL;
}
// Ensure 'len' does not exceed allocated size before copying
if (len > filename_len) {
    efree(filename_buf);
    return NULL; // or handle error appropriately
}
memcpy(filename_buf, src, len);

Why This Works

The root cause was a disconnect between allocation size and copy size — two values that should always be in lockstep were computed independently and never compared. The fix eliminates this disconnect by:

• Deriving the copy length from the same expression used for allocation, or
• Explicitly asserting that copy_length <= allocated_size before proceeding

This is a straightforward but critical invariant: never copy more bytes into a buffer than you allocated for it.

Prevention & Best Practices

1. Always Pair Allocation Size and Copy Size

The golden rule: the number of bytes you copy should never exceed the number of bytes you allocated. Treat these as an invariant and enforce it explicitly.

// Pattern: Allocate, then copy the same amount
size_t needed = compute_needed_size(input);
char *buf = malloc(needed);
assert(buf != NULL);
memcpy(buf, input, needed); // Same value used for both

2. Prefer Safer Alternatives to memcpy

Where possible, use bounds-checked alternatives:

// Using memcpy_s (C11 Annex K) - aborts if sizes don't match
errno_t err = memcpy_s(dst, dst_size, src, src_size);
if (err != 0) {
    // Handle error
}

3. Use Static Analysis Tools

These vulnerabilities are exactly what static analyzers are built to catch:

• Coverity — Industry-standard static analysis for C/C++
• CodeQL — GitHub's semantic code analysis engine (free for open source)
• Clang Static Analyzer — Built into the LLVM toolchain
• Flawfinder — Lightweight scanner that flags dangerous C functions including memcpy
• PVS-Studio — Commercial analyzer with strong C/C++ support

Many of these tools will flag memcpy calls where the length argument is not provably bounded by the destination size.

4. Enable Runtime Sanitizers During Development

Compile with sanitizers enabled in your development and CI builds:

# AddressSanitizer catches heap overflows at runtime
clang -fsanitize=address -g -o myprogram myprogram.c

# UndefinedBehaviorSanitizer catches related undefined behavior
clang -fsanitize=undefined -g -o myprogram myprogram.c

# Combine both
clang -fsanitize=address,undefined -g -o myprogram myprogram.c

AddressSanitizer (ASan) would have caught this vulnerability immediately during testing — it instruments every heap access and reports out-of-bounds writes with a precise stack trace.

5. Fuzz Your Input Parsers

Compilers and parsers are prime targets for fuzzing because they process complex, user-controlled input:

# AFL++ - industry-standard fuzzer
afl-fuzz -i input_corpus/ -o findings/ -- ./compiler @@

# libFuzzer (LLVM) - for in-process fuzzing
clang -fsanitize=fuzzer,address -o fuzz_target fuzz_target.c
./fuzz_target

Fuzzing with ASan enabled is one of the most effective ways to discover buffer overflows before attackers do.

6. Adopt a Secure Code Review Checklist

For any C/C++ code review, flag these patterns for extra scrutiny:

• [ ] Every malloc/emalloc call: is the size correct and sufficient?
• [ ] Every memcpy/memmove call: is n <= dest_size provably true?
• [ ] Every length computation: can it overflow (e.g., size_t wraparound)?
• [ ] Every user-controlled length: is it validated before use?

Relevant Security Standards

• CWE-122: Heap-based Buffer Overflow — The canonical classification for this vulnerability
• CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer — Parent class
• OWASP: Buffer Overflow — OWASP's overview and mitigation guidance
• SEI CERT C Coding Standard: MEM35-C — "Allocate sufficient memory for an object"
• NIST NVD — For tracking CVEs related to similar vulnerabilities

Conclusion

This vulnerability is a textbook example of why memory safety is non-negotiable in security-sensitive C code. A simple disconnect between two size values — one used for allocation, one used for copying — created a critical heap buffer overflow that could have enabled arbitrary code execution in systems that process untrusted PHP source files.

The fix is straightforward in hindsight: keep allocation size and copy size in sync, and validate before you copy. But the lesson is broader:

Every memcpy in C is a potential vulnerability waiting to happen if the lengths aren't carefully controlled.

The best defenses are layered: write careful code, use static analysis in CI, enable sanitizers in testing, fuzz your parsers, and review memory operations with extra scrutiny. No single technique catches everything, but together they dramatically reduce the attack surface.

Security vulnerabilities in compilers and build tools are particularly high-stakes — they sit at the foundation of the software supply chain. A compromised compiler can poison every binary it produces. Keeping these tools secure is not just good hygiene; it's essential infrastructure protection.

If you maintain C or C++ code that processes user input, audit your memcpy calls today. The few minutes it takes could prevent a critical breach tomorrow.

This vulnerability was identified and fixed by automated security scanning. The fix was verified by build testing, scanner re-scan, and LLM-assisted code review.

Automated security fix by OrbisAI Security