Heap Buffer Overflow in tzsp_forwarder.c: When Packets Attack

Heap Buffer Overflow in tzsp_forwarder.c: When Network Packets Attack Your Heap

Introduction

What if the data you were processing could secretly rewrite your program's memory? That's precisely what a heap buffer overflow allows — and it's one of the most dangerous vulnerability classes in systems programming. This week, a critical heap buffer overflow (CWE-120) was patched in contrib/tzsp_forwarder.c, a C component responsible for forwarding TZSP (TaZmen Sniffer Protocol) encapsulated network packets.

If you write C or C++ code that processes network data — or if you depend on software that does — this vulnerability and its fix are a masterclass in why never trusting attacker-controlled input is a foundational security principle.

Background: What is TZSP?

TZSP (TaZmen Sniffer Protocol) is a lightweight encapsulation protocol used to tunnel captured network packets from one device to another. It's commonly found in network monitoring equipment, wireless access points, and packet capture tools. A TZSP forwarder receives raw captured packets and re-encapsulates or relays them.

Because TZSP forwarders sit at the boundary between untrusted network data and internal processing logic, they are high-value targets for attackers. Any bug in how packet metadata is handled can have severe consequences.

The Vulnerability Explained

What Went Wrong

At line 53 of contrib/tzsp_forwarder.c, a memcpy operation copies data from a captured network packet into a destination buffer:

// VULNERABLE CODE (simplified)
memcpy(tzsp_packet + offset, captured_data, caplen);

The critical problem: caplen comes directly from the captured packet header — data that is entirely under the attacker's control. Before this fix, there was no validation to ensure that caplen bytes would actually fit into the remaining space of tzsp_packet (i.e., the allocated buffer size minus offset).

The Anatomy of the Attack

Here's what the vulnerable logic looked like conceptually:

// BEFORE: No bounds checking — DANGEROUS
uint8_t *tzsp_packet = malloc(TZSP_BUFFER_SIZE);
size_t offset = build_tzsp_header(tzsp_packet);  // some header bytes written

// caplen is read directly from the attacker-supplied packet header
uint32_t caplen = ntohl(pcap_header->caplen);

// If caplen > (TZSP_BUFFER_SIZE - offset), we overflow the heap!
memcpy(tzsp_packet + offset, packet_data, caplen);

An attacker crafts a malicious packet where the caplen field is set to a value larger than TZSP_BUFFER_SIZE - offset. When memcpy executes, it writes beyond the end of tzsp_packet, overwriting adjacent heap memory structures.

What Can an Attacker Actually Do?

Heap buffer overflows are notoriously powerful primitives for attackers. Depending on the heap layout and the target environment, exploitation can lead to:

Real-World Attack Scenario

Imagine a network monitoring appliance running this TZSP forwarder daemon with root privileges (required to open raw sockets). The appliance is connected to a mirrored switch port and receives all network traffic.

1. Attacker sends a crafted UDP packet to the TZSP listener port with caplen set to 0xFFFFFFFF (4,294,967,295 bytes).
2. The forwarder reads this value directly from the packet header without validation.
3. memcpy begins writing ~4GB of data starting at tzsp_packet + offset.
4. Within the first few kilobytes, it overwrites the metadata of adjacent heap chunks.
5. On the next malloc or free call, the heap allocator reads corrupted metadata, potentially jumping to an attacker-controlled address.
6. Game over — the attacker has code execution as root on the monitoring appliance, with visibility into all mirrored network traffic.

This isn't a theoretical scenario. CVE databases are full of real-world exploits following exactly this pattern.

The Fix

What Changed

The fix introduces bounds validation before the memcpy call. The corrected logic ensures that caplen cannot exceed the remaining available space in the destination buffer:

// AFTER: Bounds checking added — SAFE
uint8_t *tzsp_packet = malloc(TZSP_BUFFER_SIZE);
size_t offset = build_tzsp_header(tzsp_packet);

// caplen is read from the attacker-supplied packet header
uint32_t caplen = ntohl(pcap_header->caplen);

// Validate: ensure caplen fits within the remaining buffer space
if (caplen > TZSP_BUFFER_SIZE - offset) {
    // Log the anomaly and discard the malformed packet
    log_warning("Dropping packet: caplen %u exceeds buffer bounds", caplen);
    free(tzsp_packet);
    return;
}

// Now safe to copy
memcpy(tzsp_packet + offset, packet_data, caplen);

Why This Fix Works

The fix enforces a hard upper bound on caplen before it's used as the length argument to memcpy. No matter what value an attacker puts in the caplen field, the code will never write beyond the allocated buffer.

Key elements of a good fix here:

1. Explicit upper bound check: caplen > TZSP_BUFFER_SIZE - offset catches the overflow condition. Note the subtraction order matters — subtracting offset from TZSP_BUFFER_SIZE (not the other way around) avoids an integer underflow if offset > TZSP_BUFFER_SIZE.

2. Graceful rejection: Instead of truncating silently (which could cause other bugs), the malformed packet is logged and discarded. This also aids in detecting attack attempts.

3. No silent truncation: A common mistake is to "fix" this by clamping: caplen = MIN(caplen, remaining). While this prevents the overflow, it silently processes a truncated packet, which may cause protocol-level issues downstream. Dropping the packet entirely is safer.

Integer Overflow Consideration

One subtle trap: if offset is larger than TZSP_BUFFER_SIZE (which shouldn't happen but could under other bugs), the subtraction TZSP_BUFFER_SIZE - offset wraps around to a huge number, making the check useless. A fully hardened version adds a secondary guard:

// Belt-and-suspenders: also guard against offset corruption
if (offset >= TZSP_BUFFER_SIZE || caplen > TZSP_BUFFER_SIZE - offset) {
    log_warning("Dropping packet: invalid offset or caplen");
    free(tzsp_packet);
    return;
}

Conclusion

This vulnerability is a textbook example of why input validation at trust boundaries is non-negotiable in systems programming. A single missing bounds check on an attacker-controlled caplen field turned a routine memcpy into a potential remote code execution primitive.

The key takeaways from this fix:

✅ Validate all external length values before using them in memory operations

✅ Fail loudly — log and discard malformed packets rather than silently truncating

✅ Guard against integer arithmetic issues in bounds calculations

✅ Layer your defenses — compiler flags, ASLR, and least privilege all reduce impact even if a bug slips through

✅ Fuzz your parsers — automated fuzzing is highly effective at finding exactly this class of bug

Buffer overflows have been a top vulnerability class for over 30 years — since the Morris Worm in 1988. They're not going away as long as C and C++ are used for network-facing code. The tools and techniques to prevent them are well-understood; the challenge is consistently applying them.

Write the bounds check. Save the heap.

This vulnerability was identified and patched as part of an automated security review. Special thanks to the OrbisAI Security scanner for flagging this critical issue.

Found a security vulnerability? Practice responsible disclosure and report it to the project maintainers before going public.