Critical DHCP Heap Overflow: How a Missing Bounds Check Opens the Door to Memory Corruption

Introduction

Network protocols are the backbone of modern connectivity, but they also represent one of the most dangerous attack surfaces in any system. When a network-facing service trusts data from an untrusted source without validation, the consequences can be catastrophic. This post examines a critical heap buffer overflow discovered in a DHCP server implementation — a vulnerability that required just one extra line of code to fix, but could have allowed an attacker to corrupt memory and potentially execute arbitrary code.

If you write C code that handles network packets, processes binary protocols, or copies data from external sources, this vulnerability is a textbook example of what can go wrong when you trust attacker-controlled length fields.

The Vulnerability Explained

What Is a Heap Buffer Overflow?

A buffer overflow occurs when a program writes more data into a buffer than the buffer was allocated to hold. When this happens on the heap (dynamically allocated memory), an attacker can overwrite adjacent heap structures — potentially including function pointers, metadata used by the allocator, or other sensitive data. In the worst case, this leads to arbitrary code execution.

The Vulnerable Code

The vulnerability lived in components/net/lwip-dhcpd/dhcp_server_raw.c, inside the dhcp_client_alloc function:

// VULNERABLE CODE (before fix)
SMEMCPY(node->chaddr, msg->chaddr, msg->hlen);

At first glance, this looks innocent — it's copying the client hardware address (chaddr) from an incoming DHCP packet into a newly allocated node structure. But there's a critical problem: msg->hlen comes directly from the attacker-controlled DHCP packet and is never validated.

Understanding the DHCP Packet Structure

In the DHCP protocol (defined in RFC 2131), a DHCP message contains:

• chaddr: The client hardware address field — 16 bytes maximum for Ethernet addresses
• hlen: The hardware address length — a single byte that can hold values from 0 to 255

The destination buffer node->chaddr is sized for the maximum legitimate hardware address: 16 bytes. But hlen is a raw byte from the network packet. An attacker can set it to 255 — the maximum value a single byte can hold.

Here's what happens:

Destination buffer size:  16 bytes  (sized for max Ethernet HW address)
Attacker-supplied hlen:  255 bytes  (maximum byte value)
Overflow amount:         239 bytes  (255 - 16 = 239 bytes past the buffer)

239 bytes of heap overflow. That's enough to corrupt multiple adjacent heap allocations, overwrite heap allocator metadata, or stomp on other critical data structures.

The Attack Scenario

An attacker on the same network segment (or any network that can reach the DHCP server) can craft a malicious DHCP DISCOVER or REQUEST packet with hlen set to 0xFF (255). No authentication is required — DHCP is a broadcast protocol by design. When the server processes this packet and calls dhcp_client_alloc, the oversized SMEMCPY corrupts up to 239 bytes of heap memory beyond the chaddr buffer.

Attacker sends crafted DHCP packet:
┌─────────────────────────────────────────┐
│  DHCP DISCOVER                          │
│  hlen = 0xFF  (255 — attacker-set)      │
│  chaddr = [255 bytes of attacker data]  │
└─────────────────────────────────────────┘
           │
           ▼
Server calls: SMEMCPY(node->chaddr, msg->chaddr, 255)
                                              ^^^
                               Only 16 bytes allocated!
                               239 bytes overflow into heap

Depending on the heap layout and platform, this could result in:
- Denial of Service — heap corruption crashes the DHCP server or the entire system
- Remote Code Execution — carefully crafted overflow data overwrites a function pointer or return address
- Privilege Escalation — if the DHCP server runs with elevated privileges (common in embedded systems)

The Secondary Issue: Unbounded sprintf

The same file also contained two calls to sprintf when constructing IP address strings:

// VULNERABLE CODE (before fix)
sprintf(p, "%d", DHCPD_CLIENT_IP_MIN);
// ...
sprintf(p, "%d", DHCPD_CLIENT_IP_MAX);

sprintf writes into a buffer without any length limit. If the format string produces more characters than the remaining buffer space, this is another classic buffer overflow. While less immediately exploitable than the chaddr issue, it's still a latent bug waiting for the right conditions.

The Fix

Bounding the Memory Copy

The fix for the primary vulnerability is elegant in its simplicity — a ternary bounds check inline with the copy:

// FIXED CODE (after fix)
SMEMCPY(node->chaddr, msg->chaddr, 
        (msg->hlen > sizeof(node->chaddr)) ? sizeof(node->chaddr) : msg->hlen);

This is a classic min() pattern: copy whichever is smaller — the attacker-supplied length or the actual size of the destination buffer. Now, no matter what value an attacker puts in hlen, the copy will never exceed the bounds of node->chaddr.

Let's visualize the protection:

Before fix:
  hlen = 255  →  copies 255 bytes  →  OVERFLOW (239 bytes past buffer)

After fix:
  hlen = 255  →  min(255, 16) = 16  →  copies 16 bytes  →  SAFE
  hlen = 6    →  min(6, 16)  = 6   →  copies 6 bytes   →  SAFE (normal Ethernet)
  hlen = 0    →  min(0, 16)  = 0   →  copies 0 bytes   →  SAFE

Many codebases define a MIN() macro for readability. The inline ternary achieves the same result and makes the intent explicit at the call site.

Replacing sprintf with snprintf

The secondary fix replaces the unbounded sprintf calls with snprintf, which accepts a maximum length argument:

// FIXED CODE (after fix)
snprintf(p, (size_t)(str_tmp + sizeof(str_tmp) - p), "%d", DHCPD_CLIENT_IP_MIN);
// ...
snprintf(p, (size_t)(str_tmp + sizeof(str_tmp) - p), "%d", DHCPD_CLIENT_IP_MAX);

The size argument (size_t)(str_tmp + sizeof(str_tmp) - p) calculates exactly how many bytes remain in the buffer from the current write position p to the end of str_tmp. This is a precise and correct way to prevent overflows when writing into a substring of a larger buffer.

The Full Diff at a Glance

- SMEMCPY(node->chaddr, msg->chaddr, msg->hlen);
+ SMEMCPY(node->chaddr, msg->chaddr, (msg->hlen > sizeof(node->chaddr)) ? sizeof(node->chaddr) : msg->hlen);

- sprintf(p, "%d", DHCPD_CLIENT_IP_MIN);
+ snprintf(p, (size_t)(str_tmp + sizeof(str_tmp) - p), "%d", DHCPD_CLIENT_IP_MIN);

- sprintf(p, "%d", DHCPD_CLIENT_IP_MAX);
+ snprintf(p, (size_t)(str_tmp + sizeof(str_tmp) - p), "%d", DHCPD_CLIENT_IP_MAX);

Three lines changed. A critical vulnerability closed.

Prevention & Best Practices

1. Never Trust Length Fields from the Network

This is the golden rule of network programming: any field in a network packet is attacker-controlled. Length fields, offsets, counts — all of them must be validated against your own known-good values before use.

// ALWAYS validate before using network-supplied lengths
if (msg->hlen > sizeof(node->chaddr)) {
    // Log the anomaly, drop the packet, or clamp the value
    return NULL; // or: msg->hlen = sizeof(node->chaddr);
}
SMEMCPY(node->chaddr, msg->chaddr, msg->hlen);

2. Use Safe String and Memory Functions

3. Use sizeof for Buffer Size Calculations

Always use sizeof(buffer) rather than hardcoded constants. If the buffer size changes in a refactor, sizeof automatically reflects the new size:

// Fragile — breaks if buffer size changes
SMEMCPY(node->chaddr, msg->chaddr, 16);

// Robust — always correct
SMEMCPY(node->chaddr, msg->chaddr, 
        MIN(msg->hlen, sizeof(node->chaddr)));

4. Enable Compiler and Runtime Protections

Modern compilers and toolchains offer several layers of protection:

• -D_FORTIFY_SOURCE=2 — GCC/Clang: enables compile-time and runtime checks on buffer functions
• -fstack-protector-strong — adds stack canaries to detect stack overflows
• AddressSanitizer (-fsanitize=address) — detects heap overflows at runtime during testing
• Valgrind — runtime memory error detection
• Static analyzers — tools like Coverity, CodeQL, or Clang Static Analyzer can catch these patterns before code ships

5. Fuzz Your Protocol Parsers

DHCP, DNS, HTTP, and other protocol parsers are prime targets for fuzzing. Tools like AFL++ or libFuzzer can automatically generate malformed packets — including ones with maximum-value length fields — to discover exactly this class of vulnerability.

# Example: fuzzing a network parser with AFL++
afl-fuzz -i corpus/ -o findings/ -- ./dhcp_parser_harness @@

6. Relevant Security Standards

This vulnerability maps to well-known security weakness classifications:

• CWE-122: Heap-based Buffer Overflow
• CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer
• CWE-20: Improper Input Validation
• OWASP: A03:2021 – Injection (which includes memory injection via buffer overflows)
• CERT C: Rule ARR38-C — Guarantee that library functions do not form invalid pointers

Conclusion

This vulnerability is a perfect illustration of a timeless truth in systems programming: the distance between a safe program and a critically vulnerable one can be as small as a missing bounds check. One SMEMCPY call, one unvalidated length field, and an attacker gains the ability to corrupt 239 bytes of heap memory in a network-facing service.

The fix is equally instructive — not a complex architectural change, but a simple, targeted bounds check that costs nothing in performance and closes the vulnerability completely. Good security is often less about heroic engineering and more about disciplined, consistent application of basic principles.

Key takeaways for developers:

1. ✅ Validate all length fields from network packets before using them in memory operations
2. ✅ Prefer snprintf over sprintf — there is almost never a good reason to use sprintf
3. ✅ Use sizeof(buffer) in copy operations to make size relationships explicit and refactor-safe
4. ✅ Fuzz your protocol implementations — automated fuzzing finds exactly these edge cases
5. ✅ Enable compiler sanitizers in your test and CI builds to catch overflows before they reach production

Security vulnerabilities in network-facing C code are not inevitable — they are preventable with consistent application of well-understood practices. Every bounds check you add is an attack vector you close.

This vulnerability was automatically detected and fixed by OrbisAI Security. Automated security scanning can identify critical issues like this one before they reach production.