1368873 - OpenH264: UBSan index out of bounds in [@WelsDec::WelsInitRefList]

Status: RESOLVED FIXED

(Core :: Audio/Video: GMP, defect)

Description

[Tyson Smith [:tsmith]]

Attachment: test_case.264

Found while fuzzing openh264 revision eac070c0b.

I'm not sure if this is a false positive, I tried detecting the issue with ASan and Valgrind with no success. Maybe compiler optimization is complicating things?

Build with "-fsanitize=undefined"

To reproduce:
./h264dec testcase.264 /dev/null

codec/decoder/core/src/manage_dec_ref.cpp:170:5: runtime error: index 17 out of bounds for type 'PPicture [17]'
    #0 0x5dd36f in WelsDec::WelsInitRefList(WelsDec::TagWelsDecoderContext*, int) codec/decoder/core/src/manage_dec_ref.cpp:170:48
    #1 0x58138f in WelsDec::InitRefPicList(WelsDec::TagWelsDecoderContext*, unsigned char, int) codec/decoder/core/src/decoder_core.cpp:2203:10
    #2 0x58138f in WelsDec::DecodeCurrentAccessUnit(WelsDec::TagWelsDecoderContext*, unsigned char**, TagBufferInfo*) codec/decoder/core/src/decoder_core.cpp:2399
    #3 0x57c7d3 in WelsDec::ConstructAccessUnit(WelsDec::TagWelsDecoderContext*, unsigned char**, TagBufferInfo*) codec/decoder/core/src/decoder_core.cpp:2131:10
    #4 0x54599e in WelsDecodeBs codec/decoder/core/src/decoder.cpp:789:7
    #5 0x5269d9 in WelsDec::CWelsDecoder::DecodeFrame2(unsigned char const*, int, unsigned char**, TagBufferInfo*) codec/decoder/plus/src/welsDecoderExt.cpp:546:3
    #6 0x524c34 in WelsDec::CWelsDecoder::DecodeFrameNoDelay(unsigned char const*, int, unsigned char**, TagBufferInfo*) codec/decoder/plus/src/welsDecoderExt.cpp:472:11
    #7 0x515c7e in H264DecodeInstance(ISVCDecoder*, char const*, char const*, int&, int&, char const*, char const*) codec/console/dec/src/h264dec.cpp:221:15
    #8 0x517579 in main codec/console/dec/src/h264dec.cpp:360:5
    #9 0x7f6e5303e82f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
    #10 0x41cc38 in _start (h264dec+0x41cc38)

Comment 1

[wayne]

It is a real potential bug. Will fix it in master soon. Thanks.

Comment 2

[wayne]

the bug has been fixed by commit 986f3d0 in master. Could you please check it? Thanks.

Comment 3

[Tyson Smith [:tsmith]]

Verified fixed with openh264 commit 986f3d0. Thank you.

Comment 4

[Randell Jesup [:jesup] (needinfo me)]

Note that this will be fixed in the next OpenH264 deployment.  When we you plan to release the next plugin version?  Should we spin a new version with a point fix for this issue (instead of a full update to the current state of the source)?

Comment 5

[wayne]

we will release an openh264 version 1.7.1 for this fix soon. Will inform you when it is ready.

Comment 6

[Frederik Braun [:freddy]]

(In reply to wayne from comment #5)
> we will release an openh264 version 1.7.1 for this fix soon. Will inform you
> when it is ready.

Any updates?

Comment 7

[wayne]

(In reply to Frederik Braun [:freddyb] from comment #6)
> (In reply to wayne from comment #5)
> > we will release an openh264 version 1.7.1 for this fix soon. Will inform you
> > when it is ready.
> 
> Any updates?

Hi Frederik, we have already informed some guys from Mozilla to test 1.7.1 branch. I'm sure it is still in test status.

Comment 8

[Hank Peng]

Hi Maire, any plan about picking up the openh264 plugin v1.7.1?

Comment 9

[Randell Jesup [:jesup] (needinfo me)]

sec-moderate, given non-obvious ability to leverage this into an exploit, and that the exploit must then escape the GMP sandbox

Comment 10

[Maire Reavy [:mreavy]]

(In reply to Hank Peng from comment #8)
> Hi Maire, any plan about picking up the openh264 plugin v1.7.1?

Hi Hank, Yes - I'm coordinating with the releng team (at Mozilla). They are super busy, and there are no critical sec bugs driving v1.7.1; so I'm about to ask them to target getting this ready for deployment by mid-August so we can get it to release users by end of August.  If you see any problems with this timing, please needinfo me back or send me email.  Thanks!

Comment 11

[Ryan VanderMeulen [:RyanVM]]

We're shipping v1.7.1 to all supported channels now, so I think we can call this bug fixed.