1479656 - OpenH264: heap-buffer-overflow in [@ McCopyWidthEq4_c]

Status: RESOLVED FIXED

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

Description

[Tyson Smith [:tsmith]]

Attachment: testcase.264

Found while fuzzing openh264 revision f92a006bb05dce89f312df8a641a65abf09076c8

Build with "-fsanitize=address"

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

==26397==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x627000018d20 at pc 0x00000078f19b bp 0x7ffd70aed780 sp 0x7ffd70aed778
WRITE of size 4 at 0x627000018d20 thread T0
    #0 0x78f19a in (anonymous namespace)::McCopyWidthEq4_c(unsigned char const*, int, unsigned char*, int, int) codec/common/src/mc.cpp:113:5
    #1 0x78f19a in (anonymous namespace)::McCopy_sse2(unsigned char const*, int, unsigned char*, int, int, int) codec/common/src/mc.cpp:445
    #2 0x786ad5 in (anonymous namespace)::McChroma_ssse3(unsigned char const*, int, unsigned char*, int, short, short, int, int) codec/common/src/mc.cpp:899:5
    #3 0x619c49 in WelsDec::BaseMC(WelsDec::TagMCRefMember*, int, int, TagMcFunc*, int, int, short*) codec/decoder/core/src/rec_mb.cpp:266:3
    #4 0x628963 in WelsDec::GetInterBPred(unsigned char**, unsigned char**, WelsDec::TagWelsDecoderContext*) codec/decoder/core/src/rec_mb.cpp:777:13
    #5 0x6a23ed in WelsDec::WelsMbInterConstruction(WelsDec::TagWelsDecoderContext*, WelsDec::TagDqLayer*) codec/decoder/core/src/decode_slice.cpp:219:5
    #6 0x69fe29 in WelsDec::WelsTargetMbConstruction(WelsDec::TagWelsDecoderContext*) codec/decoder/core/src/decode_slice.cpp:327:7
    #7 0x69da17 in WelsDec::WelsTargetSliceConstruction(WelsDec::TagWelsDecoderContext*) codec/decoder/core/src/decode_slice.cpp:102:11
    #8 0x59af9e in WelsDec::WelsDecodeConstructSlice(WelsDec::TagWelsDecoderContext*, WelsDec::TagNalUnit*) codec/decoder/core/src/decoder_core.cpp:290:19
    #9 0x59af9e in WelsDec::DecodeCurrentAccessUnit(WelsDec::TagWelsDecoderContext*, unsigned char**, TagBufferInfo*) codec/decoder/core/src/decoder_core.cpp:2566
    #10 0x595d93 in WelsDec::ConstructAccessUnit(WelsDec::TagWelsDecoderContext*, unsigned char**, TagBufferInfo*) codec/decoder/core/src/decoder_core.cpp:2252:10
    #11 0x55a69e in WelsDecodeBs codec/decoder/core/src/decoder.cpp:798:7
    #12 0x52e365 in WelsDec::CWelsDecoder::DecodeFrame2(unsigned char const*, int, unsigned char**, TagBufferInfo*) codec/decoder/plus/src/welsDecoderExt.cpp:570:3
    #13 0x52c4f4 in WelsDec::CWelsDecoder::DecodeFrameNoDelay(unsigned char const*, int, unsigned char**, TagBufferInfo*) codec/decoder/plus/src/welsDecoderExt.cpp:495:11
    #14 0x516b49 in H264DecodeInstance(ISVCDecoder*, char const*, char const*, int&, int&, char const*, char const*, int, bool) codec/console/dec/src/h264dec.cpp:226:17
    #15 0x51c34f in main codec/console/dec/src/h264dec.cpp:510:3
    #16 0x7f241499f82f in __libc_start_main /build/glibc-Cl5G7W/glibc-2.23/csu/../csu/libc-start.c:291
    #17 0x41d638 in _start (h264dec+0x41d638)

Comment 1

[Daniel Veditz [:dveditz]]

because of the possibility of overwriting a pointer going with a bit higher rating.

Tyson: would be helpful if you marked the current Firefox versions "unaffected" or "affected" as appropriate. This is found upstream, but not clear whether you've checked our version for it.

Comment 2

[wayne]

Hi Tyson, could you please add the following guy to trace the bug? thanks. I'm unable to add him to CC list.
[e-mail]
This person will also be responsible for several recent bugs.

Comment 3

[Tyson Smith [:tsmith]]

(In reply to wayne from comment #2)
> Hi Tyson, could you please add the following guy to trace the bug? thanks.
> I'm unable to add him to CC list.
> [e-mail]
> This person will also be responsible for several recent bugs.

I can but only once that email address is link to a bugzilla account. Ping me once this is handled and I will add the CCs. Thanks.

Comment 4

[wayne]

I added him into list (seems I can also do this if email address linked).
Xiaotianshi, please follow related bugs. Thanks.

Comment 5

[xiaotian shi]

The issue has been addressed by openh264 #PR 3011

Comment 6

[xiaotian shi]

The issue has been addressed by openh264 #PR 3011

Comment 7

[Tyson Smith [:tsmith]]

This issue is still reproducible in commit 1b3980b3437e83f30001e9b7dfdf4a98e69b87bc

Comment 8

[xiaotian shi]

Yes, understood the problem now. It is caused by multi-sequence stream. It will need to re-allocate MotionVectors in ref picture when new sequence changes picture size. This will take some time to fix.

Comment 9

[wayne]

This bug has been fixed in latest openh265 master. Please kindly have a look. Thanks.

Comment 10

[Tyson Smith [:tsmith]]

Verified with openh264 commit 70eeb783515dbfee3e0c781d6667838caba5113b