Looks like the openh264-1.6.0 release silently fixed some potential vulnerabilities: > ================================================================= > ==4637==ERROR: AddressSanitizer: heap-use-after-free on address 0x62f000092410 at pc 0x00000042fa6a bp 0x7ffeffda4c00 sp 0x7ffeffda4bf0 > READ of size 1 at 0x62f000092410 thread T0 > #0 0x42fa69 in WelsDec::FmoNextMb(WelsDec::TagFmo*, short) (/root/asan/openh264/h264dec+0x42fa69) > #1 0x471797 in WelsDec::WelsDecodeSlice(WelsDec::TagWelsDecoderContext*, bool, WelsDec::TagNalUnit*) (/root/asan/openh264/h264dec+0x471797) > #2 0x424170 in WelsDec::DecodeCurrentAccessUnit(WelsDec::TagWelsDecoderContext*, unsigned char**, TagBufferInfo*) (/root/asan/openh264/h264dec+0x424170) > #3 0x4275e8 in WelsDec::ConstructAccessUnit(WelsDec::TagWelsDecoderContext*, unsigned char**, TagBufferInfo*) (/root/asan/openh264/h264dec+0x4275e8) > #4 0x40db32 in WelsDecodeBs (/root/asan/openh264/h264dec+0x40db32) > #5 0x4089b9 in WelsDec::CWelsDecoder::DecodeFrameNoDelay(unsigned char const*, int, unsigned char**, TagBufferInfo*) (/root/asan/openh264/h264dec+0x4089b9) > #6 0x404995 in H264DecodeInstance(ISVCDecoder*, char const*, char const*, int&, int&, char const*, char const*) (/root/asan/openh264/h264dec+0x404995) > #7 0x402be3 in main (/root/asan/openh264/h264dec+0x402be3) > #8 0x7f4c8cec082f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f) > #9 0x403608 in _start (/root/asan/openh264/h264dec+0x403608) > > 0x62f000092410 is located 24592 bytes inside of 48147-byte region [0x62f00008c400,0x62f000098013) > freed by thread T0 here: > #0 0x7f4c8dba22ca in __interceptor_free (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x982ca) > #1 0x42f182 in WelsDec::InitFmo(WelsDec::TagFmo*, WelsDec::TagPps*, int, int, WelsCommon::CMemoryAlign*) (/root/asan/openh264/h264dec+0x42f182) > #2 0x42f883 in WelsDec::FmoParamUpdate(WelsDec::TagFmo*, WelsDec::TagSps*, WelsDec::TagPps*, int*, WelsCommon::CMemoryAlign*) (/root/asan/openh264/h264dec+0x42f883) > #3 0x423772 in WelsDec::DecodeCurrentAccessUnit(WelsDec::TagWelsDecoderContext*, unsigned char**, TagBufferInfo*) (/root/asan/openh264/h264dec+0x423772) > #4 0x4275e8 in WelsDec::ConstructAccessUnit(WelsDec::TagWelsDecoderContext*, unsigned char**, TagBufferInfo*) (/root/asan/openh264/h264dec+0x4275e8) > #5 0x40e70f in WelsDecodeBs (/root/asan/openh264/h264dec+0x40e70f) > #6 0x406ef9 in WelsDec::CWelsDecoder::DecodeFrame2(unsigned char const*, int, unsigned char**, TagBufferInfo*) [clone .part.3] [clone .constprop.6] (/root/asan/openh264/h264dec+0x406ef9) > #7 0x408678 in WelsDec::CWelsDecoder::DecodeFrameNoDelay(unsigned char const*, int, unsigned char**, TagBufferInfo*) (/root/asan/openh264/h264dec+0x408678) > #8 0x404995 in H264DecodeInstance(ISVCDecoder*, char const*, char const*, int&, int&, char const*, char const*) (/root/asan/openh264/h264dec+0x404995) > #9 0x402be3 in main (/root/asan/openh264/h264dec+0x402be3) > #10 0x7f4c8cec082f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f) > > previously allocated by thread T0 here: > #0 0x7f4c8dba2602 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x98602) > #1 0x4b5a78 in WelsCommon::WelsMalloc(unsigned int, char const*, unsigned int) (/root/asan/openh264/h264dec+0x4b5a78) > #2 0x4b5b64 in WelsCommon::CMemoryAlign::WelsMalloc(unsigned int, char const*) (/root/asan/openh264/h264dec+0x4b5b64) > #3 0x4b5c0f in WelsCommon::CMemoryAlign::WelsMallocz(unsigned int, char const*) (/root/asan/openh264/h264dec+0x4b5c0f) > #4 0x42f19a in WelsDec::InitFmo(WelsDec::TagFmo*, WelsDec::TagPps*, int, int, WelsCommon::CMemoryAlign*) (/root/asan/openh264/h264dec+0x42f19a) > #5 0x42f883 in WelsDec::FmoParamUpdate(WelsDec::TagFmo*, WelsDec::TagSps*, WelsDec::TagPps*, int*, WelsCommon::CMemoryAlign*) (/root/asan/openh264/h264dec+0x42f883) > #6 0x423772 in WelsDec::DecodeCurrentAccessUnit(WelsDec::TagWelsDecoderContext*, unsigned char**, TagBufferInfo*) (/root/asan/openh264/h264dec+0x423772) > #7 0x4275e8 in WelsDec::ConstructAccessUnit(WelsDec::TagWelsDecoderContext*, unsigned char**, TagBufferInfo*) (/root/asan/openh264/h264dec+0x4275e8) > #8 0x40db32 in WelsDecodeBs (/root/asan/openh264/h264dec+0x40db32) > #9 0x4089b9 in WelsDec::CWelsDecoder::DecodeFrameNoDelay(unsigned char const*, int, unsigned char**, TagBufferInfo*) (/root/asan/openh264/h264dec+0x4089b9) > #10 0x404995 in H264DecodeInstance(ISVCDecoder*, char const*, char const*, int&, int&, char const*, char const*) (/root/asan/openh264/h264dec+0x404995) > #11 0x402be3 in main (/root/asan/openh264/h264dec+0x402be3) > #12 0x7f4c8cec082f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f) > > SUMMARY: AddressSanitizer: heap-use-after-free ??:0 WelsDec::FmoNextMb(WelsDec::TagFmo*, short) > Shadow bytes around the buggy address: > 0x0c5e8000a430: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd > 0x0c5e8000a440: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd > 0x0c5e8000a450: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd > 0x0c5e8000a460: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd > 0x0c5e8000a470: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd > =>0x0c5e8000a480: fd fd[fd]fd fd fd fd fd fd fd fd fd fd fd fd fd > 0x0c5e8000a490: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd > 0x0c5e8000a4a0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd > 0x0c5e8000a4b0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd > 0x0c5e8000a4c0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd > 0x0c5e8000a4d0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd > 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 > ==4637==ABORTING See $URL for the source of the report. I was yet unable to get further information from other sources.
@ Maintainer(s): Please bump the package to >=media-libs/openh264-1.6.0 and let us know if it is ready for the stabilization or not.
@maintainer(s), please let us know when you are ready to call for stable or call for it here yourself.
I'm not sure how much testing it's had in the wild, but I'm good to stabilize.
ia64 stable
amd64 stable
I stabilized because of the chromium security bug which has this bug as a depends on. However, from the stacktrace I don't see the library involved (libopenh264.so) so since it is a read issue in a command-line tool I'd suggest to do not track it as a security issue.
arm stable
x86 stable
alpha stable
ppc/ppc64 stable
hppa stable
@maintainers, please clean.
cleanup done. GLSA Vote: No Thank you all,
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=f40f3445169c77e50fc912a4d64d4cc6ca1b6c38 commit f40f3445169c77e50fc912a4d64d4cc6ca1b6c38 Author: Rolf Eike Beer <eike@sf-mail.de> AuthorDate: 2018-04-16 20:05:34 +0000 Commit: Sergei Trofimovich <slyfox@gentoo.org> CommitDate: 2018-04-16 20:43:36 +0000 media-libs/openh264: stable 1.7.0-r1 for sparc Bug: https://bugs.gentoo.org/604420 Package-Manager: Portage-2.3.24, Repoman-2.3.6 RepoMan-Options: --include-arches="sparc" media-libs/openh264/openh264-1.7.0-r1.ebuild | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)}
