Critical Buffer Overflow in Cache.c: How Unsigned Integer Underflow Opens the Door to Remote Code Execution

Severity: 🔴 Critical | File: src/cache.c:1121 | CVE Class: CWE-119 (Improper Restriction of Operations within the Bounds of a Memory Buffer)

Introduction

Somewhere in the vast landscape of software bugs, few are as simultaneously subtle and catastrophic as the unsigned integer underflow leading to a buffer overflow. It looks innocent at a glance — just a subtraction and a memory copy — but under the right conditions, it hands an attacker the keys to your process's memory.

This post breaks down a recently patched critical vulnerability in src/cache.c, explains exactly how it could be weaponized, and walks through the best practices that prevent this class of bug from ever reaching production.

If you write C, review C, or ship software that depends on C libraries (hint: almost everyone does), this one's for you.

The Vulnerability Explained

What Was the Code Doing?

At line 1121 of src/cache.c, the code was performing a memcpy to transfer data from a receive buffer (recv_buf) into an output buffer (output_buf). The intent was straightforward: copy send bytes from a calculated position within the receive buffer into the output.

The problematic logic looked something like this:

// VULNERABLE CODE (illustrative reconstruction)
size_t copy_offset = offset_start - dl_offset;  // ⚠️ No validation
memcpy(output_buf, recv_buf + copy_offset, send); // ⚠️ No bounds check

Three things were missing, and each one is a loaded gun:

1. No validation that offset_start >= dl_offset before the subtraction
2. No bounds check confirming the source range stays within recv_buf
3. No validation that send bytes don't exceed output_buf's allocated capacity

The Silent Killer: Unsigned Integer Underflow

In C, size_t is an unsigned type. This is important. When you subtract a larger value from a smaller one using unsigned integers, you don't get a negative number — you get a massive positive number due to wraparound arithmetic.

size_t offset_start = 10;
size_t dl_offset    = 50;

size_t result = offset_start - dl_offset;
// Expected (if signed): -40
// Actual (unsigned):    18446744073709551576  (on 64-bit systems)

That enormous value is now used as a pointer offset into recv_buf. The resulting pointer doesn't point anywhere near your buffer — it points to some arbitrary location in the process's address space, potentially including:

• Other heap allocations containing sensitive data
• Stack frames with return addresses
• Function pointers or vtables

How Could It Be Exploited?

The vulnerability note highlights a critical detail: both offset_start and dl_offset are influenced by attacker-controlled network responses. This means a remote attacker can:

1. Craft a malicious network response that sets offset_start to a value smaller than dl_offset
2. Trigger the underflow, causing recv_buf + copy_offset to point to an attacker-chosen memory region
3. Control send to specify how many bytes get copied, potentially overflowing output_buf

This creates two distinct but related attack primitives:

Real-World Attack Scenario

Imagine this application fetches content from a remote server and caches it locally. An attacker controls a malicious server (or performs a man-in-the-middle attack on an unprotected connection):

[Attacker's Server]
  │
  │  Crafted HTTP response:
  │  Content-Range: bytes 9999999-10000000/10000001
  │  (where dl_offset > offset_start after processing)
  │
  ▼
[Vulnerable Application]
  │
  │  offset_start = 5
  │  dl_offset    = 100
  │  copy_offset  = 5 - 100 = 18446744073709551521 (underflow!)
  │
  ▼
[memcpy reads from recv_buf + 18446744073709551521]
  → Reads from arbitrary memory location
  → Potentially writes attacker-influenced data into output_buf + overflow
  → Process corruption / RCE

This is not a theoretical scenario. Vulnerabilities of this exact class have led to real-world exploits in widely deployed software, including web servers, media parsers, and network daemons.

The Fix

What Changed

The patch introduced explicit bounds validation before the memcpy is ever executed. The fix follows a "validate everything, trust nothing" approach for values derived from network input.

A properly hardened version of this code enforces three invariants:

// FIXED CODE (illustrative)

// 1. Validate that subtraction won't underflow
if (offset_start < dl_offset) {
    // Log error, return failure — do NOT proceed
    log_error("Invalid offset: offset_start (%zu) < dl_offset (%zu)",
              offset_start, dl_offset);
    return CACHE_ERR_INVALID_OFFSET;
}

size_t copy_offset = offset_start - dl_offset;

// 2. Validate source range stays within recv_buf
if (copy_offset >= recv_buf_size || send > recv_buf_size - copy_offset) {
    log_error("Source range out of bounds");
    return CACHE_ERR_OUT_OF_BOUNDS;
}

// 3. Validate destination capacity
if (send > output_buf_size) {
    log_error("send (%zu) exceeds output_buf capacity (%zu)",
              send, output_buf_size);
    return CACHE_ERR_OVERFLOW;
}

// Safe to proceed
memcpy(output_buf, recv_buf + copy_offset, send);

Why This Fix Works

Each check addresses a specific attack vector:

• Check 1 prevents the unsigned underflow entirely. If the math would produce a nonsensical result, we fail fast and loudly.
• Check 2 ensures the source pointer and length stay within the allocated bounds of recv_buf, preventing out-of-bounds reads.
• Check 3 ensures we never write more bytes than output_buf can hold, preventing heap/stack corruption.

The key insight is that all three checks must be present. A common mistake is to add only one or two guards, leaving a remaining attack surface.

A Note on the Broader Context

The vulnerability report also references a separate concern: OAuth tokens and API keys stored in plaintext on the filesystem. While that issue involves different code (plugins/auth-oauth2/src/store.ts), it's worth noting that memory safety vulnerabilities and credential storage weaknesses often compound each other. An attacker who achieves out-of-bounds read capability via a bug like this one could potentially exfiltrate plaintext credentials from adjacent memory regions — making both issues more dangerous in combination than either is alone.

Defense in depth means fixing both classes of vulnerability, not just the most obvious one.

Conclusion

The vulnerability patched in src/cache.c is a textbook example of why low-level memory management demands meticulous validation of every value that crosses a trust boundary. The bug itself — an unsigned integer underflow enabling out-of-bounds memory access — is simple to describe but potentially catastrophic in impact, enabling everything from information disclosure to full remote code execution.

The key takeaways:

• Unsigned arithmetic doesn't protect you from underflow — it makes it silent and dangerous
• Network-controlled values must be validated before use in pointer arithmetic or size calculations
• All three invariants must hold: no underflow, source in bounds, destination in bounds
• Tooling exists to catch this: ASan, UBSan, and fuzzers can find these bugs before attackers do
• Code review checklists for memory operations are a lightweight, high-value practice

Security is a discipline, not a feature. Every memcpy that touches external data is a potential vulnerability waiting for the wrong input. The fix here is straightforward — validate before you calculate, check before you copy — and applying that discipline consistently is what separates resilient software from exploitable software.

Stay safe, validate your inputs, and may your pointers always stay in bounds. 🔐

This post is part of our ongoing series on real-world security vulnerabilities and their fixes. Automated security analysis powered by OrbisAI Security.