1106398 - Openh264: ASAN heap-buffer-overflow in WelsDec::WelsDecodeSlice

Status: RESOLVED FIXED

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

Description

[Nils]

Attachment: repro.264 (minimised testcase)

The attached testcase crashes an ASAN build of the Firefox branch of openh264 ( https://github.com/cisco/openh264/tree/v1.1-Firefox34 ) as follows:

=================================================================
==852==ERROR: AddressSanitizer: heap-buffer-overflow on address 0xf6100a18 at pc 0x081b536e bp 0xff9760a8 sp 0xff9760a0
WRITE of size 4 at 0xf6100a18 thread T0
    #0 0x81b536d in WelsDec::WelsDecodeSlice(WelsDec::TagWelsDecoderContext*, bool, WelsDec::TagNalUnit*) (/home/nils/264/h264dec-ff+0x81b536d)
    #1 0x8145d47 in WelsDec::DecodeCurrentAccessUnit(WelsDec::TagWelsDecoderContext*, unsigned char**, TagBufferInfo*) (/home/nils/264/h264dec-ff+0x8145d47)
    #2 0x8141c9d in WelsDec::ConstructAccessUnit(WelsDec::TagWelsDecoderContext*, unsigned char**, TagBufferInfo*) (/home/nils/264/h264dec-ff+0x8141c9d)
    #3 0x8123d6d in WelsDecodeBs (/home/nils/264/h264dec-ff+0x8123d6d)
    #4 0x811d193 in WelsDec::CWelsDecoder::DecodeFrame2(unsigned char const*, int, unsigned char**, TagBufferInfo*) (/home/nils/264/h264dec-ff+0x811d193)
    #5 0x8115778 in H264DecodeInstance(ISVCDecoder*, char const*, char const*, int&, int&, char const*) (/home/nils/264/h264dec-ff+0x8115778)
    #6 0x8118774 in main (/home/nils/264/h264dec-ff+0x8118774)
    #7 0xf73e3a82  (/lib/i386-linux-gnu/libc.so.6+0x19a82)
    #8 0x807cd8b in _start (/home/nils/264/h264dec-ff+0x807cd8b)

0xf6100a1b is located 0 bytes to the right of 27-byte region [0xf6100a00,0xf6100a1b)
allocated by thread T0 here:
    #0 0x80f0cdb in malloc /home/bobthebuilder/llvm/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:40:3
    #1 0x8182c7f in WelsMalloc (/home/nils/264/h264dec-ff+0x8182c7f)

SUMMARY: AddressSanitizer: heap-buffer-overflow ??:0 WelsDec::WelsDecodeSlice(WelsDec::TagWelsDecoderContext*, bool, WelsDec::TagNalUnit*)
Shadow bytes around the buggy address:
  0x3ec200f0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x3ec20100: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x3ec20110: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x3ec20120: fa fa fa fa fa fa fa fa 00 00 00 fa fa fa 00 00
  0x3ec20130: 00 fa fa fa 00 00 00 fa fa fa 00 00 00 fa fa fa
=>0x3ec20140: 00 00 00[03]fa fa 00 00 00 03 fa fa 00 00 00 fa
  0x3ec20150: fa fa 00 00 00 fa fa fa 00 00 00 07 fa fa 00 00
  0x3ec20160: 00 fa fa fa 00 00 00 fa fa fa 00 00 00 fa fa fa
  0x3ec20170: 00 00 04 fa fa fa 00 00 06 fa fa fa 00 00 06 fa
  0x3ec20180: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x3ec20190: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Heap right redzone:      fb
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack partial redzone:   f4
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
==852==ABORTING

Comment 1

[wayne]

Thanks for the information. 
Checked it with latest openh264 codec (master), and it should be fixed by the pull request #1589.
Could you please check if it is OK with latest codec? Thanks.
If OK, we can schedule and update new codec.

Comment 2

[Daniel Veditz [:dveditz]]

https://github.com/cisco/openh264/pull/1589
https://rbcommons.com/s/OpenH264/r/962/

Randell: can we push plugin updates off cycle, or are openh264 updates sync'd to firefox releases?

Comment 3

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

We can push updates anytime we want for OpenH264, though we've generally synced them to releases (for GMP API changes).  The design purposely lets us update it without chemspilling the browser.

Comment 4

[Lukas Blakk [:lsblakk] use ?needinfo]

If updates to OpenH264 can be done without browser rebuilds, this isn't a tracking issue.

Comment 5

[Ethan Hugg [:ehugg]]

OpenH264 1.3 has this fix and is now downloaded for Firefox 34+ so marking this as fixed.