Heap Buffer Overflow in HAL Filter: How Unvalidated memcpy Sizes Can Sink Your App

Severity: Critical | CWE: CWE-120 (Buffer Copy Without Checking Size of Input) | File: hal/ndsrvp/src/filter.cpp

Introduction

Deep inside the hardware abstraction layer (HAL) of many image-processing pipelines lives a class of bug that has haunted C and C++ codebases for decades: the unchecked buffer copy. It's quiet, it's fast, and under the right conditions, it's catastrophic.

This week, a critical vulnerability (V-001) was patched in hal/ndsrvp/src/filter.cpp — a component responsible for image filtering operations including bilateral filtering and median blur. The root cause? Multiple calls to memcpy that computed their byte-count arguments from user-influenced values (image dimensions, channel counts, border parameters) without ever verifying that the computed size fit within the destination buffer.

If you write C or C++ code that processes external data — especially image data — this post is for you. Even if you don't, understanding heap buffer overflows is foundational security knowledge that applies across languages and platforms.

The Vulnerability Explained

What Is a Heap Buffer Overflow?

A buffer overflow occurs when a program writes more data into a memory buffer than the buffer was allocated to hold. When this happens on the heap (dynamically allocated memory), adjacent heap metadata and other allocated objects get overwritten — a condition known as heap corruption.

The C standard library function memcpy is a frequent offender:

memcpy(destination, source, n_bytes);

memcpy will copy exactly n_bytes bytes from source to destination. It does not check whether destination is large enough. That responsibility falls entirely on the programmer.

What Was Wrong in filter.cpp?

The vulnerable code appeared in several filter routines — the ndsrvp HAL filter, bilateral filter, and median blur — and followed a pattern like this:

// VULNERABLE: size computed from external inputs, never validated
size_t copy_size = cnes * (rborder - j);
memcpy(dst_buffer, src_ptr, copy_size);

Or similarly:

// VULNERABLE: src_step and height come from image metadata
memcpy(temp_buf, src, src_step * height);

The variables involved — cnes, cn (channel count), rborder, j, src_step, height — are all derived directly or indirectly from image file metadata. An attacker who controls the image file controls these values.

The Math That Kills You

Consider a simplified version of the problem:

• dst_buffer is allocated as width * height * channels bytes for a "normal" image.
• The copy size is computed as cn * (rborder - j).
• If an attacker crafts an image where cn = 4 and (rborder - j) = 0x40000000, the computed size becomes 1 GB — far exceeding any reasonable allocation.

Even without integer overflow, subtly wrong values can cause the copy to spill just a few hundred bytes past the buffer boundary — enough to overwrite a heap chunk header, a function pointer stored nearby, or security-critical data.

How Could This Be Exploited?

Step 1 — Craft a malicious image. The attacker creates an image file with manipulated metadata: unusual dimensions, an abnormally large channel count, or border parameters that cause arithmetic to produce a large computed size.

Step 2 — Feed it to the application. Any code path that loads and processes this image using the vulnerable filter routines triggers the overflow.

Step 3 — Corrupt heap memory. The oversized memcpy writes past the end of the destination buffer, overwriting adjacent heap allocations.

Step 4 — Achieve impact. Depending on what's adjacent in memory, the attacker may be able to:
- Crash the application (Denial of Service)
- Leak sensitive data from adjacent heap objects (Information Disclosure)
- Overwrite function pointers or vtables to redirect execution (Remote Code Execution)

Real-World Impact

Image processing libraries are ubiquitous. They're embedded in:
- Web servers that resize user-uploaded images
- Mobile apps that apply filters to photos
- Desktop applications that open documents
- IoT devices with camera inputs
- CI/CD pipelines that process build artifacts

A single malicious JPEG, PNG, or raw image file could be the vector. The attacker doesn't need network access beyond the ability to submit a file — a low bar in most applications that accept user content.

The Fix

What Changed

The fix applied to hal/ndsrvp/src/filter.cpp addresses the core problem: computed copy sizes must be validated against the actual size of the destination buffer before calling memcpy.

The corrected pattern looks like this:

// BEFORE (vulnerable)
size_t copy_size = cnes * (rborder - j);
memcpy(dst_buffer, src_ptr, copy_size);

// AFTER (safe)
size_t copy_size = cnes * (rborder - j);

// Validate computed size before copy
CV_Assert(copy_size <= dst_buffer_size);
// or equivalently:
if (copy_size > dst_buffer_size) {
    // Handle error: reject input, log, return early
    return;
}

memcpy(dst_buffer, src_ptr, copy_size);

For the src_step * height pattern:

// BEFORE (vulnerable)
memcpy(temp_buf, src, src_step * height);

// AFTER (safe)
size_t required = src_step * height;
CV_Assert(required <= temp_buf_allocated_size);
memcpy(temp_buf, src, required);

Why This Works

By asserting (or explicitly checking) that the computed size fits within the allocated buffer before calling memcpy, we ensure that:

1. Attacker-controlled values cannot drive the copy past the buffer boundary.
2. Malformed inputs are rejected early, before they can cause memory corruption.
3. The program fails safely — either by asserting in debug builds (helping developers catch bugs) or by returning an error in production.

Overflow-Safe Size Arithmetic

An additional concern with expressions like cnes * (rborder - j) and src_step * height is integer overflow. On 32-bit platforms (or when using 32-bit types), two large values multiplied together can wrap around to a small number, bypassing a naive size check:

// Dangerous: if src_step=0x10000 and height=0x10001 on 32-bit,
// the product wraps to a small value — check passes, but memcpy still overflows
if (src_step * height <= buf_size) { ... }

The safe approach uses overflow-checked arithmetic:

// Safe multiplication with overflow check
size_t required;
if (__builtin_mul_overflow(src_step, height, &required) || required > buf_size) {
    return; // reject
}
memcpy(temp_buf, src, required);

Or use a helper function:

// Using a checked multiply utility
size_t required = checked_mul(src_step, height); // throws/returns error on overflow

Conclusion

The vulnerability patched in hal/ndsrvp/src/filter.cpp is a textbook example of CWE-120 — a buffer copy where the size argument is derived from untrusted external data without validation. It's the kind of bug that's easy to write, hard to spot in code review, and potentially devastating in exploitation.

The key takeaways:

1. Computed sizes are dangerous. Any memcpy size that involves external data must be bounds-checked before use.
2. Integer overflow can defeat naive checks. Use overflow-safe arithmetic when computing sizes.
3. Defense in depth matters. ASan, fuzzing, and static analysis catch what human reviewers miss.
4. Image processing is high-risk territory. Files are attacker-controlled input. Treat every field in every format as hostile.

Security in systems programming isn't about being perfect — it's about building habits and tooling that make the dangerous patterns visible before they reach production. This fix is a good reminder that even low-level, performance-critical code deserves the same security scrutiny as any public-facing API.

Stay safe, validate your sizes, and fuzz your parsers. 🔒

This vulnerability was identified and patched as part of an automated security review by OrbisAI Security. Automated scanning is one layer of defense — combine it with manual review, fuzzing, and developer education for the strongest security posture.