The attached testcase crashes the ASAN build of h264dec of the upcoming openh264 firefox branch (https://github.com/cisco/openh264/tree/v1.3-Firefox36). The ASAN build has been compiled with USE_ASM=No. It crashes the ASM optimised build unreliably. The testcases crashes both the 32-bit and 64-bit build. ASAN output: ================================================================= ==28675==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x7f9927835820 at pc 0x00000056aa76 bp 0x7fff16ed82d0 sp 0x7fff16ed82c8 WRITE of size 4 at 0x7f9927835820 thread T0 #0 0x56aa75 in WelsDec::McChroma_c(unsigned char const*, int, unsigned char*, int, short, short, int, int) (/home/nils/264/h264dec-ff-1.3-64+0x56aa75) #1 0x570801 in WelsDec::GetInterPred(unsigned char*, unsigned char*, unsigned char*, WelsDec::TagWelsDecoderContext*) (/home/nils/264/h264dec-ff-1.3-64+0x570801) #2 0x5a3776 in WelsDec::WelsTargetMbConstruction(WelsDec::TagWelsDecoderContext*) (/home/nils/264/h264dec-ff-1.3-64+0x5a3776) #3 0x5a283b in WelsDec::WelsTargetSliceConstruction(WelsDec::TagWelsDecoderContext*) (/home/nils/264/h264dec-ff-1.3-64+0x5a283b) #4 0x5202ce in WelsDec::DecodeCurrentAccessUnit(WelsDec::TagWelsDecoderContext*, unsigned char**, TagBufferInfo*) (/home/nils/264/h264dec-ff-1.3-64+0x5202ce) #5 0x51a86a in WelsDec::ConstructAccessUnit(WelsDec::TagWelsDecoderContext*, unsigned char**, TagBufferInfo*) (/home/nils/264/h264dec-ff-1.3-64+0x51a86a) #6 0x4fb580 in WelsDecodeBs (/home/nils/264/h264dec-ff-1.3-64+0x4fb580) #7 0x4ef44b in WelsDec::CWelsDecoder::DecodeFrame2(unsigned char const*, int, unsigned char**, TagBufferInfo*) (/home/nils/264/h264dec-ff-1.3-64+0x4ef44b) #8 0x4e7bf6 in H264DecodeInstance(ISVCDecoder*, char const*, char const*, int&, int&, char const*) (/home/nils/264/h264dec-ff-1.3-64+0x4e7bf6) #9 0x4ead40 in main (/home/nils/264/h264dec-ff-1.3-64+0x4ead40) #10 0x7f9929c4dec4 (/lib/x86_64-linux-gnu/libc.so.6+0x21ec4) #11 0x43e596 in _start (/home/nils/264/h264dec-ff-1.3-64+0x43e596) 0x7f9927835820 is located 5 bytes to the right of 184347-byte region [0x7f9927808800,0x7f992783581b) allocated by thread T0 here: #0 0x4c58b2 in malloc /home/nils/build/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:40:3 #1 0x56ad61 in WelsMalloc (/home/nils/264/h264dec-ff-1.3-64+0x56ad61) SUMMARY: AddressSanitizer: heap-buffer-overflow ??:0 WelsDec::McChroma_c(unsigned char const*, int, unsigned char*, int, short, short, int, int) Shadow bytes around the buggy address: 0x0ff3a4efeab0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0ff3a4efeac0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0ff3a4efead0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0ff3a4efeae0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0ff3a4efeaf0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 =>0x0ff3a4efeb00: 00 00 00 03[fa]fa fa fa fa fa fa fa fa fa fa fa 0x0ff3a4efeb10: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0ff3a4efeb20: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0ff3a4efeb30: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0ff3a4efeb40: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0ff3a4efeb50: 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 Left alloca redzone: ca Right alloca redzone: cb ==28675==ABORTING
Thanks for the information. The problem is fixed in openh264 codec master (https://github.com/cisco/openh264/pull/1673), and v1.3 (https://github.com/cisco/openh264/commit/917d683bb25906ea7506cc531e56d241a558a5d0) Could you please check if it is OK with either? Thanks.
Component: WebRTC: Audio/Video → OpenH264
Product: Core → Plugins
Version: Trunk → unspecified
According to my testing, this one is fixed by this commit which has now been merged into the v1.3-Firefox36 branch: https://github.com/cisco/openh264/commit/5c114c3ebb6d6477e5cbf1c52b9f08a7cb4d18c0
5 years ago
Jesup - taking a stab in the dark here but are you a person who can assign someone to getting this nominated for uplift to all versions?
(In reply to Lukas Blakk [:lsblakk] use ?needinfo from comment #4) > Jesup - taking a stab in the dark here but are you a person who can assign > someone to getting this nominated for uplift to all versions? This is a bug in the upstream plugin, which is a separate build and update channel from Firefox, and 1.3 is currently being tested for full deployment on beta/aurora/nightly.
OpenH264 1.3 has this fix and is now downloaded for Firefox 34+ so marking this as fixed.
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.