CVE-2022-43245 - A Deep Dive Into Libde265 v1..8’s Denial of Service Vulnerability

Libde265 is a famous open source library used for decoding HEVC (High Efficiency Video Coding), also known as H.265 videos. It's used in plenty of projects from media players to online streaming. However, in 2022, a segmentation violation, now known as CVE-2022-43245, was discovered in libde265 v1..8. This bug allows attackers to easily crash software using libde265, just by feeding it a specially crafted video file.

In this article, I’ll explain what went wrong, why it matters, and how attackers could exploit it. We’ll take a look at some real code, references, and steps for mitigation—using simple, clear language that anyone can follow.

What Is CVE-2022-43245?

Simply put, CVE-2022-43245 is a segmentation violation (also known as a “segfault”) in the function apply_sao_internal<unsigned short> found in the source file sao.cc of libde265 v1..8. When libde265 tries decoding a specially-crafted video, it may try to access memory it shouldn’t—leading to a crash.

In non-technical terms:  
It’s a bug that lets someone crash any program using this decoder if they make a funky video. No code execution, but a strong DoS (Denial of Service).

Technical Details

Libde265 uses functions in sao.cc to apply a technique called “Sample Adaptive Offset” during video decoding. There’s a C++ template function like this:

template<typename pixel_t>
void apply_sao_internal(/* params */) {
    // ... process pixel data ...
    pixel_t* out = output_buffer;
    for (int i = ; i < width * height; i++) {
        // Safe processing? Not quite...
        out[i] = calculate_pixel_value(i);
    }
}

The problem shows up when the function reads or writes out-of-bounds in memory, typically caused by skipping proper checks on input sizes or corrupt data in the crafted media file.

Vulnerable Excerpt (Pseudo-code)

// In sao.cc, simplified for clarity
pixel_t *out = output_buffer;
for (int y = ; y < height; y++) {
    for (int x = ; x < width; x++) {
        int offset = y * stride + x;
        // No check if 'offset' is valid!
        out[offset] = process(...);
    }
}

If the supplied video file provides a width or height that doesn't match the output buffer size, or other corrupted header data, offset could go past the end of the buffer. That’s how an attacker triggers a segmentation fault.

Craft a Malicious HEVC Video

The attacker creates a fake but valid-looking HEVC video file, setting width/height and other fields to trick libde265’s logic.

Deliver the File

The attacker uploads, emails, or makes their video reachable by any user-facing app that decodes video using libde265 (think: chat apps, CMS, media players, web services).

Crash the App

The app tries to play or scan the video, hitting the apply_sao_internal function. The malformed size causes memory access outside the allowed zone, crashing the process. This could, for example:

Sample Exploit Script

Here’s a very minimal Python pseudo-script to show triggering such bugs, assuming you have a tool to construct custom HEVC files (often done with ffmpeg or custom code):

# WARNING: For educational purpose only!

from subprocess import run

# Create a tiny/corrupted video with out-of-range size fields 
# (In real research, you'd hex-edit the raw HEVC header fields)
run([
    'ffmpeg', '-f', 'lavfi', '-i', 'testsrc=duration=1:size=4x4:rate=1', 
    '-vcodec', 'libx265', '-y', 'malicious.hevc'
])

# Now, you would hex-edit 'malicious.hevc' to tweak frame sizes in NAL units
# and test with a player using vulnerable libde265, e.g.:
# ./simple_play malicious.hevc

Again, actually building a working PoC generally uses a hex editor, fuzzers, and careful study of file format specs. Still, the main method is simple: poison the header so that the internal logic of the decoding function miscalculates its memory.

Original References

- CVE-2022-43245 entry @ NVD
- libde265 Issue/Commit where this was reported
- Upstream Patch
- Project official site

Upgrade Immediately:

Versions after commit 6ffec05 include bounds checks to prevent the out-of-bounds write.

Do Not Trust Media Files:

Never blindly process or auto-play user-uploaded media in production without updating and sandboxing!

Use Process Sandboxing:

If you run file processing as a web service, run it in a tightly confined environment, so even if it crashes, the rest of your system is protected.

Conclusion

CVE-2022-43245 is a classic example of what happens when open source libraries don’t strictly validate file content against allocated memory. Though it doesn’t allow code execution, the ease with which any attacker can crash an app using libde265 means you should take it seriously, especially if you build video software or process user uploads. Always patch your third-party code, audit for bounds checks, and monitor for updates in core dependencies.

Stay safe—and keep your video code sharp!

*Feel free to share this post, cite with attribution, and always check official sources for the latest.*

Timeline

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