Opened 16 months ago

Closed 16 months ago

Last modified 16 months ago

#9155 closed defect (needs_more_info)

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

Reported by: Jonas Witschel Owned by:
Priority: normal Component: avcodec
Version: unspecified Keywords:
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no


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?

Change History (6)

comment:1 by Carl Eugen Hoyos, 16 months ago

Resolution: needs_more_info
Status: newclosed

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.

comment:2 by Jonas Witschel, 16 months ago

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).

comment:3 by Carl Eugen Hoyos, 16 months ago

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

comment:4 by Jonas Witschel, 16 months ago

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 (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.

in reply to:  4 comment:5 by Carl Eugen Hoyos, 16 months ago

Replying to diabonas:

it is not a simple FFmpeg crash

It is here.

comment:6 by Carl Eugen Hoyos, 16 months ago

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.

Note: See TracTickets for help on using tickets.