libde265 is a popular open-source library used for decoding videos in the H.265/HEVC format. On October 27, 2022, a heap-buffer-overflow vulnerability (CVE-2022-43253) was discovered in version 1..8. If you’re using this or an older version of libde265, your application might be exposed to a risk: An attacker can craft a malicious H.265 video file that triggers this bug, resulting in a Denial of Service (DoS) by crashing the program.

Let me walk you through what this means, how it works, and what you can do about it—with code to illustrate and resources to dig deeper.

What’s the Problem?

The issue is found in the function put_unweighted_pred_16_fallback within the file fallback-motion.cc. When this function processes crafted input, it can write data outside of the space it’s supposed to use (heap buffer), which could crash the app or make it behave in strange ways.

- CVE-2022-43253 NIST Summary
- libde265 GitHub Repo
- OSS-Fuzz Issue #51967, the Original Fuzzing Report
- Source code: fallback-motion.cc (as of v1..8)

How Does the Vulnerability Work?

The vulnerable code is related to how libde265 handles reference frames in video files—a core part of how video compression works. Specific code in the function doesn't check boundaries for a memory write operation. If an attacker provides a specially-crafted video, it tricks libde265 into writing past the end of an allocated memory block, causing a buffer overflow on the heap.

Let's see the simplified vulnerable code

// fallback-motion.cc (libde265 1..8)

void put_unweighted_pred_16_fallback(pixel *dst, intptr_t dstStride,
                                     const pixel *src, intptr_t srcStride,
                                     int width, int height)
{
    for (int y = ; y < height; y++) {
        memcpy(dst, src, width * sizeof(pixel)); // <--- No bounds check
        dst += dstStride;
        src += srcStride;
    }
}

If the input parameters width, height, dstStride, or srcStride are bad (via a malformed video), this code can write to locations outside the allocated dst buffer, corrupting memory.

What Can Go Wrong?

Usually, this bug results in a crash (DoS). In harder scenarios, if an attacker can control the overwritten data, this could, in theory, lead to remote code execution (though there's no public evidence of this yet).

Craft a Dangerous Video File:

Use fuzzing (random data generator) or manual tuning to create a valid-looking .hevc file with carefully chosen frame data.

Trigger the Bug:

Feed this file into any tool using libde265 (like dec265, GStreamer plugins, browser plugins, or any video app that's not updated).

The app crashes due to heap corruption.

Here’s a Python snippet (using subprocess to run dec265 decoder) that shows how a crafted file can be tested:

import subprocess

# Assume 'crash.hevc' is a malicious file that triggers the bug
try:
    result = subprocess.run(["dec265", "crash.hevc"], timeout=5, capture_output=True)
    if result.returncode != :
        print("Program crashed (possibly due to heap overflow)!")
except Exception as e:
    print(str(e))

Note: The crafted file is not shared here, but on OSS-Fuzz you can find more technical details and crash traces.

Developers can spot this bug using AddressSanitizer (ASAN). Here's a typical crash trace

==1234==ERROR: AddressSanitizer: heap-buffer-overflow on address x6030000001f at pc x7f2da1b4ddb9 bp x7ffdcf3ccd sp x7ffdcf3ccc8
WRITE of size 16 at x6030000001f thread T
# x7f2da1b4ddb8 in put_unweighted_pred_16_fallback .../libde265/fallback-motion.cc:70
...

How to Fix It

- Upgrade Now: This bug is fixed in libde265 v1..10 and later.

Conclusion

CVE-2022-43253 is a classic example of how a tiny oversight in video processing can become a big problem. While it’s “just a crash” for now, it's a strong reminder of why input validation and up-to-date dependencies are critical, especially for libraries that handle complex, user-supplied data like video files.

More Reading

- libde265 Release Notes (fix mentions)
- What is a Heap Buffer Overflow?
- Reporting Security Issues to libde265


*This post is written just for you, using open information and exclusive research. Stay secure!*

Timeline

Published on: 11/02/2022 14:15:00 UTC
Last modified on: 02/27/2023 15:26:00 UTC