1257707 - Crash [@ avpriv_flac_parse_block_header] with MP4/H264

Status: RESOLVED FIXED

(Core :: Audio/Video: Playback, defect, P3)

Description

[Christian Holler (:decoder)]

The attached testcase crashes on mozilla-inbound revision f30fc906416f (build with --enable-optimize --disable-debug --enable-address-sanitizer).

For detailed crash information, see attachment.

To reproduce the issue, you can run the testcase through the "MediaDataDecoder.H264" gtest. Example STR:

1. Change into objdir/dist/bin of your Firefox build
2. Place attached testcase into objdir, keep the name "gizmo.mp4"
3. Run: GTEST_FILTER=MediaDataDecoder.H264 MOZ_RUN_GTEST=1 ./firefox -unittest


This crash seems to happen inside the libavcodec library (tested on Ubuntu 14.04), but I don't get it with avplay so it could be that the bug is in our code instead.

I'm also marking this s-s (for now) because the 0x470 seems quite far away from the 0x0 already. If the offset can be controlled arbitrarily, it might lead to a security problem.

Comment 1

[Christian Holler (:decoder)]

Attachment: Detailed Crash Information

Comment 2

[Christian Holler (:decoder)]

Attachment: Testcase

Comment 3

[Anthony Jones (:ajones, :kentuckyfriedtakahe, :k17e)]

Jean-Yves - do we need to upstream this?

Comment 4

[Jean-Yves Avenard [:jya]]

Sure. I don't see how we could ever end up in the flac decoder seeing that we don't support flac and never configure the ffmpeg decoder to decode flac.

Comment 5

[Jean-Yves Avenard [:jya]]

Having said that. :decoder has an ancient LibAV version, one that likely don't exist in ffmpeg.

Comment 6

[Christian Holler (:decoder)]

It should be noted that this is the default on Ubuntu 14.04 LTS and ffmpeg does not exist there. So this is a default configuration, not some obscure one.

Comment 7

[Anthony Jones (:ajones, :kentuckyfriedtakahe, :k17e)]

Christian - we either need to get the issue fixed upstream or drop support for libavcodec on Ubuntu 14.04. Can you file a bug with Ubuntu?

Comment 8

[Jean-Yves Avenard [:jya]]

What about trying to fix this bug first and submitting that upstream.

I can't reproduce the issue with the sample provided however, so it's likely the same as with bug 1268718.

Please provide the actual file to reproduce the problem first. thanks

Comment 9

[Christian Holler (:decoder)]

Discussed this with :jya on IRC, he'll look into the issue again tomorrow (restoring needinfo for that).

When I filed this bug, I confirmed that it reproduces, I also gave :jya access to the libav upstream bug that might be the same issue.

Comment 10

[Jean-Yves Avenard [:jya]]

the fix has been submitted upstream; I see no way on how we could get around it from our side.

Most of the discussion about the actual progress was made in bug 1263665

Comment 11

[Jean-Yves Avenard [:jya]]

BTW, there's very little movement from the LibAV team; they did find a bug in my fix which I fixed very quickly. but nothing since.

I have the gutfeel that there will be no more movement from there. Maybe we should submit the patch to debian/ubuntu instead.

Comment 12

[Anthony Jones (:ajones, :kentuckyfriedtakahe, :k17e)]

Mass change P2 -> P3

Comment 13

[Jean-Yves Avenard [:jya]]

This was fixed upstream. and now libavcodec with the vulnerabilities have been blacklisted