Backporting of fixes for CVE-2020-35965/oss-fuzz issue 26532 to FFmpeg 4.3

[Jonas Witschel]

I have a question regarding the backporting of the fixes for ​CVE-2020-35965, also tracked as ​oss-fuzz issue 26532, to the FFmpeg 4.3 branch.

According to the CVE description and the oss-fuzz issue details, this vulnerability is fixed by two commits, ​b0a8b40294ea212c1938348ff112ef1b9bf16bb3 ("avcodec/exr: skip bottom clearing loop when its outside the image") and ​3e5959b3457f7f1856d997261e6ac672bba49e8b ("avcodec/exr: Check ymin vs. h").

However, only the latter seems to have been backported to the release/4.3 branch (as commit ​a53ffb15d8ae9bed14041b4cf62e436852e95431) and thus has been included in the FFmpeg 4.3.2 release. Is this correct, or does the former commit need to be backported as well?

[Carl Eugen Hoyos]

This is a bug tracker, not a support forum.
That being said: I cannot reproduce an issue with release 4.3 (or 4.3.1) and the given sample.

[Jonas Witschel]

Personally, I would consider a potentially incomplete fix for a security issue a bug, not a support request...

I am somewhat confused: if oss-fuzz issue 26532 was never present on the FFmpeg 4.3 branch, then why was commit 3e5959b3457f7f1856d997261e6ac672bba49e8b ("avcodec/exr: Check ymin vs. h") explicitly backported to FFmpeg 4.3.2 at all, and why not in combination with commit b0a8b40294ea212c1938348ff112ef1b9bf16bb3 ("avcodec/exr: skip bottom clearing loop when its outside the image")?

My worry is that the issue could still be present in FFmpeg 4.3.2 and might just require a slightly different reproducer there: after all, the earliest release that commit 3e5959b3457f7f1856d997261e6ac672bba49e8b has been backported to is 4.3.2, so even if that commit is enough to fix the issue, the problem should still be reproducible in FFmpeg 4.3.1 somehow. If it isn't reproducible in version 4.3.1 as well, this would mean one of two things:

1. The bug was never present on the 4.3 branch to begin with (the good case), or
2. The reproducer doesn't apply to the 4.3 branch and the issue might only be partially fixed (less great).

[Carl Eugen Hoyos]

If you need more information I suggest that you test yourself.

[Jonas Witschel]

I am afraid I don't have the capacity to verify the testcase myself: it is not a simple FFmpeg crash, but a heap buffer write overflow found using an address sanitiser during fuzzing. I currently lack the disk space to run the official oss-fuzz Dockerfiles as described on ​https://google.github.io/oss-fuzz/advanced-topics/reproducing/ (these become huge quickly), and I am not familiar enough with the FFmpeg codebase to know how to build it with ASAN enabled.

My suggestion would be backporting commit b0a8b40294ea212c1938348ff112ef1b9bf16bb3 to the 4.3 branch just out of caution, but obviously this is not for me to decide.

[Carl Eugen Hoyos]

Replying to diabonas:

it is not a simple FFmpeg crash

It is here.

[Carl Eugen Hoyos]

You can build FFmpeg with ASAN enabled by using the configure option --toolchain=clang-asan or the configure option --toolchain=gcc-asan but this is not needed for many issues such as this one.