Re: How to report a bunch of mplayer bugs
On 23.12.2015 12:25, Gustavo Grieco wrote: >> On 22.12.2015 16:15, Gustavo Grieco wrote: >> This list is not very useful. Please provide at least backtraces (with the >> necessary -dbg >> packages installed). > > I have the valgrind and gdb backtraces just here (attached). Thanks. >> Please test your samples with mplayer/ffmpeg from Debian unstable/testing or >> Ubuntu xenial. > > Compiling the last snapshot version from the mplayer repository is not the > same? (i'm using mplayer-export-2015-12-18) > I verified that there is no linked libraries matching "libav*" in the > resulting mplayer binary. I think these mplayer-export tarballs don't contain a copy of ffmpeg anymore, so it will probably be disabled, unless you enable it manually. Anyway, can you reproduce your crashes with this snapshot version of mplayer? On 23.12.2015 12:25, Gustavo Grieco wrote: > file > SIGBUS.PC.5704be.STACK.5c9a551.CODE.128.ADDR.(nil).INSTR.callq__0xfff3c6e2.fuzz > Program received signal SIGBUS, Bus error. > 0x005704be in play (af=0xa65e20, data=0x7fffd3f0) at > libaf/af_lavcresample.c:130 This looks like something corrupted the buffer, so that RESIZE_LOCAL_BUFFER crashes. It happens in code using libavcodec, so please test this with a current version of that library. > file > SIGFPE.PC.432d0e.STACK.18b3c0fcd4.CODE.1.ADDR.0x432d0e.INSTR.idivl__0x560ca8(%rip)#_0x00560cae.fuzz > Program received signal SIGFPE, Arithmetic exception. > 0x00432d0e in fill_audio_out_buffers () at mplayer.c:2160 > file > SIGFPE.PC.4bf2c3.STACK.1bca543b66.CODE.1.ADDR.0x4bf2c3.INSTR.divl___0x80(%rsi).fuzz > Program received signal SIGFPE, Arithmetic exception. > 0x004bf2c3 in init (sh_audio=0xa65ba0) at libmpcodecs/ad_msadpcm.c:93 These two are division by zero problems and the code looks unchanged in current mplayer trunk, so they have to be fixed in upstream mplayer. > file > SIGFPE.PC.73ceed83.STACK.d7d8808dd.CODE.1.ADDR.0x73ceed83.INSTR.idiv___%r8d.fuzz > Program received signal SIGFPE, Arithmetic exception. > 0x73ceed83 in av_resample () from > /usr/lib/x86_64-linux-gnu/libavcodec.so.54 This crash happens in libavcodec, but the backtrace is not very useful, because you don't have the debugging symbols installed. Please retest this with a current libavcodec. Also the crashing function is now deprecated and will be removed in the future... > file > SIGSEGV.PC.4bd833.STACK.18b2dd10ac.CODE.1.ADDR.0xa.INSTR.movzwl_0xa(%rax),%ecx.fuzz > Program received signal SIGSEGV, Segmentation fault. > decode_audio (sh_audio=0xa65ba0, buf=0xa6c900 "", minlen=, > maxlen=131072) at libmpcodecs/ad_dk3adpcm.c:259 > file > SIGSEGV.PC.4be46b.STACK.1aba63653d.CODE.1.ADDR.(nil).INSTR.movzbl_(%rcx,%rdx,1),%ecx.fuzz > Program received signal SIGSEGV, Segmentation fault. > 0x004be46b in ac3dts_fillbuff (sh_audio=0xa65bc0) at > libmpcodecs/ad_hwac3.c:110 I'm not sure why these crash, but they might be related. > file > SIGSEGV.PC.5704be.STACK.5c9a551.CODE.1.ADDR.0x7aaf0e08.INSTR.callq__0xfff3c6e2.fuzz > Program received signal SIGSEGV, Segmentation fault. > 0x005704be in play (af=0xaccb80, data=0x7fffd3e0) at > libaf/af_lavcresample.c:130 > file > SIGSEGV.PC.5704be.STACK.5c9a551.CODE.1.ADDR.0x7efcecd8.INSTR.callq__0xfff3c6e2.fuzz > Program received signal SIGSEGV, Segmentation fault. > 0x005704be in play (af=0xaccb80, data=0x7fffd3e0) at > libaf/af_lavcresample.c:130 > file > SIGSEGV.PC.5704be.STACK.5c9a551.CODE.1.ADDR.0x7f48eff8.INSTR.callq__0xfff3c6e2.fuzz > Program received signal SIGSEGV, Segmentation fault. > 0x005704be in play (af=0xaccb80, data=0x7fffd3e0) at > libaf/af_lavcresample.c:130 > 130 libaf/af_lavcresample.c: No such file or directory. > file > SIGSEGV.PC.5704be.STACK.5c9a551.CODE.1.ADDR.0x7f54e258.INSTR.callq__0xfff3c6e2.fuzz > Program received signal SIGSEGV, Segmentation fault. > 0x005704be in play (af=0xaccb80, data=0x7fffd3e0) at > libaf/af_lavcresample.c:130 > 130 libaf/af_lavcresample.c: No such file or directory. > file > SIGSEGV.PC.5704be.STACK.5c9a551.CODE.1.ADDR.0x7f60c128.INSTR.callq__0xfff3c6e2.fuzz > Program received signal SIGSEGV, Segmentation fault. > 0x005704be in play (af=0xaccb80, data=0x7fffd3e0) at > libaf/af_lavcresample.c:130 > 130 libaf/af_lavcresample.c: No such file or directory. > file > SIGSEGV.PC.5704be.STACK.5c9a551.CODE.1.ADDR.0x7f60d498.INSTR.callq__0xfff3c6e2.fuzz > Program received signal SIGSEGV, Segmentation fault. > 0x005704be in play (af=0xaccb80, data=0x7fffd3e0) at > libaf/af_lavcresample.c:130 > 130 libaf/af_lavcresample.c: No such file or directory. > Playing > SIGSEGV.PC.5704be.STACK.5c9a551.CODE.1.ADDR.0x7f60d4a8.INSTR.callq__0xfff3c6e2.fuzz. > Program received signal SIGSEGV, Segmentation fault. > 0x005704be in
Re: How to report a bunch of mplayer bugs
- Original Message - > Hi Gustavo, > > On 22.12.2015 16:15, Gustavo Grieco wrote: > > I'm the main developer and maintainer of QuickFuzz, a free and open-source > > experimental > > grammar fuzzer. I recently made a quick test of Mplayer version shipped > > with Ubuntu 14.04 > > and found a few interesting crashes trying to play malformed wav files. > > These crashes are > > de-duplicated by Honggfuzz, so they should be more or less independent > > (although, some are > > definitely related). > > Thanks for your effort! :D > > This list is not very useful. Please provide at least backtraces (with the > necessary -dbg > packages installed). I have the valgrind and gdb backtraces just here (attached). > > > I think some of them can be security issues (that's why they are not linked > > in this email). > > I want to handle such test cases to some trusted maintainers of Mplayer and > > avoid spamming the > > bug tracker. I already ask upstream > > (http://permalink.gmane.org/gmane.comp.video.mplayer.devel/64515) > > and they told me that mplayer 1.1 is unsupported, so i'm re-testing for the > > last cve revision. > > I suspect that most the the issues you found are not even bugs in mplayer, > but rather Libav, > which is used in Ubuntu 14.04. > We've switched back to FFmpeg recently and I suspect most/all of the issues > you found > don't affect it. > > Please test your samples with mplayer/ffmpeg from Debian unstable/testing or > Ubuntu xenial. Compiling the last snapshot version from the mplayer repository is not the same? (i'm using mplayer-export-2015-12-18) I verified that there is no linked libraries matching "libav*" in the resulting mplayer binary. > > Best regards, > Andreas > file SIGBUS.PC.5704be.STACK.5c9a551.CODE.128.ADDR.(nil).INSTR.callq__0xfff3c6e2.fuzz MPlayer 1.1-4.8 (C) 2000-2012 MPlayer Team mplayer: could not connect to socket mplayer: No such file or directory Failed to open LIRC support. You will not be able to use your remote control. Playing SIGBUS.PC.5704be.STACK.5c9a551.CODE.128.ADDR.(nil).INSTR.callq__0xfff3c6e2.fuzz. libavformat version 54.20.4 (external) Mismatching header version 54.20.3 Audio only file format detected. Load subtitles in ./ == Opening audio decoder: [pcm] Uncompressed PCM audio decoder AUDIO: -520093687 Hz, 1 ch, s16le, 0.0 kbit/-0.00% (ratio: 6->-1040187374) Selected audio codec: [pcm] afm: pcm (Uncompressed PCM) == AO: [null] -520093687Hz 1ch s16le (2 bytes per sample) Video: no video Starting playback... Audio device got stuck! A: -0.0 (unknown) of 1.0 (01.0) ??,?% -0.00x [J ==21445== Invalid write of size 8 ==21445==at 0x5704BE: play (af_lavcresample.c:130) ==21445== Address 0xfff3f6eb8 is not stack'd, malloc'd or (recently) free'd ==21445== ==21445== Can't extend stack to 0xfff3f5f68 during signal delivery for thread 1: ==21445== no stack segment ==21445== ==21445== Process terminating with default action of signal 11 (SIGSEGV) ==21445== Access not within mapped region at address 0xFFF3F5F68 ==21445==at 0x5704BE: play (af_lavcresample.c:130) ==21445== If you believe this happened as a result of a stack ==21445== overflow in your program's main thread (unlikely but ==21445== possible), you can try to increase the size of the ==21445== main thread stack using the --main-stacksize= flag. ==21445== The main thread stack size used in this run was 8388608. ==21445== Invalid write of size 8 ==21445==at 0x4A256B0: _vgnU_freeres (in /usr/lib/valgrind/vgpreload_core-amd64-linux.so) ==21445== Address 0xfff3f6e30 is not stack'd, malloc'd or (recently) free'd ==21445== ==21445== ==21445== Process terminating with default action of signal 11 (SIGSEGV) ==21445== Access not within mapped region at address 0xFFF3F6E30 ==21445==at 0x4A256B0: _vgnU_freeres (in /usr/lib/valgrind/vgpreload_core-amd64-linux.so) ==21445== If you believe this happened as a result of a stack ==21445== overflow in your program's main thread (unlikely but ==21445== possible), you can try to increase the size of the ==21445== main thread stack using the --main-stacksize= flag. ==21445== The main thread stack size used in this run was 8388608. ./show.sh: line 1: 21445 Segmentation fault valgrind --quiet mplayer -vo null -ao null "$f" file SIGFPE.PC.432d0e.STACK.18b3c0fcd4.CODE.1.ADDR.0x432d0e.INSTR.idivl__0x560ca8(%rip)#_0x00560cae.fuzz MPlayer 1.1-4.8 (C) 2000-2012 MPlayer Team mplayer: could not connect to socket mplayer: No such file or directory Failed to open LIRC support. You will not be able to use your remote control. Playing SIGFPE.PC.432d0e.STACK.18b3c0fcd4.CODE.1.ADDR.0x432d0e.INSTR.idivl__0x560ca8(%rip)#_0x00560cae.fuzz. libavformat version 54.20.4 (external) Mismatching header version 54.20.3 Audio only file format detected. Load
How to report a bunch of mplayer bugs
Hello, I'm the main developer and maintainer of QuickFuzz, a free and open-source experimental grammar fuzzer. I recently made a quick test of Mplayer version shipped with Ubuntu 14.04 and found a few interesting crashes trying to play malformed wav files. These crashes are de-duplicated by Honggfuzz, so they should be more or less independent (although, some are definitely related). The list is here: SIGBUS.PC.5704be.STACK.5c9a551.CODE.128.ADDR.(nil).INSTR.callq__0xfff3c6e2.fuzz SIGFPE.PC.432d0e.STACK.18b3c0fcd4.CODE.1.ADDR.0x432d0e.INSTR.idivl__0x560ca8(%rip)#_0x00560cae.fuzz SIGFPE.PC.4bf2c3.STACK.1bca543b66.CODE.1.ADDR.0x4bf2c3.INSTR.divl___0x80(%rsi).fuzz SIGFPE.PC.73ceed83.STACK.d7d8808dd.CODE.1.ADDR.0x73ceed83.INSTR.idiv___%r8d.fuzz SIGSEGV.PC.4bd833.STACK.18b2dd10ac.CODE.1.ADDR.0xa.INSTR.movzwl_0xa(%rax),%ecx.fuzz SIGSEGV.PC.4be46b.STACK.1aba63653d.CODE.1.ADDR.(nil).INSTR.movzbl_(%rcx,%rdx,1),%ecx.fuzz SIGSEGV.PC.5704be.STACK.5c9a551.CODE.1.ADDR.0x7aaf0e08.INSTR.callq__0xfff3c6e2.fuzz SIGSEGV.PC.5704be.STACK.5c9a551.CODE.1.ADDR.0x7efcecd8.INSTR.callq__0xfff3c6e2.fuzz SIGSEGV.PC.5704be.STACK.5c9a551.CODE.1.ADDR.0x7f48eff8.INSTR.callq__0xfff3c6e2.fuzz SIGSEGV.PC.5704be.STACK.5c9a551.CODE.1.ADDR.0x7f54e258.INSTR.callq__0xfff3c6e2.fuzz SIGSEGV.PC.5704be.STACK.5c9a551.CODE.1.ADDR.0x7f60c128.INSTR.callq__0xfff3c6e2.fuzz SIGSEGV.PC.5704be.STACK.5c9a551.CODE.1.ADDR.0x7f60d498.INSTR.callq__0xfff3c6e2.fuzz SIGSEGV.PC.5704be.STACK.5c9a551.CODE.1.ADDR.0x7f60d4a8.INSTR.callq__0xfff3c6e2.fuzz SIGSEGV.PC.5704be.STACK.5c9a551.CODE.1.ADDR.0x7f60daa8.INSTR.callq__0xfff3c6e2.fuzz SIGSEGV.PC.5704be.STACK.5c9a551.CODE.1.ADDR.0x7f60db58.INSTR.callq__0xfff3c6e2.fuzz SIGSEGV.PC.5704be.STACK.5c9a551.CODE.1.ADDR.0x7f6429a8.INSTR.callq__0xfff3c6e2.fuzz SIGSEGV.PC.5947b5.STACK.1b0df30f87.CODE.1.ADDR.(nil).INSTR.movzbl_(%rcx,%rdx,1),%ecx.fuzz SIGSEGV.PC.7fffefe7314e.STACK.18f3cc3594.CODE.1.ADDR.(nil).INSTR.movdqu_%xmm8,(%rdi,%rcx,1).fuzz I think some of them can be security issues (that's why they are not linked in this email). I want to handle such test cases to some trusted maintainers of Mplayer and avoid spamming the bug tracker. I already ask upstream (http://permalink.gmane.org/gmane.comp.video.mplayer.devel/64515) and they told me that mplayer 1.1 is unsupported, so i'm re-testing for the last cve revision. Regards, Gus. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: How to report a bunch of mplayer bugs
Hi Gustavo, On 22.12.2015 16:15, Gustavo Grieco wrote: > I'm the main developer and maintainer of QuickFuzz, a free and open-source > experimental > grammar fuzzer. I recently made a quick test of Mplayer version shipped with > Ubuntu 14.04 > and found a few interesting crashes trying to play malformed wav files. These > crashes are > de-duplicated by Honggfuzz, so they should be more or less independent > (although, some are > definitely related). Thanks for your effort! > The list is here: > > SIGBUS.PC.5704be.STACK.5c9a551.CODE.128.ADDR.(nil).INSTR.callq__0xfff3c6e2.fuzz > SIGFPE.PC.432d0e.STACK.18b3c0fcd4.CODE.1.ADDR.0x432d0e.INSTR.idivl__0x560ca8(%rip)#_0x00560cae.fuzz > SIGFPE.PC.4bf2c3.STACK.1bca543b66.CODE.1.ADDR.0x4bf2c3.INSTR.divl___0x80(%rsi).fuzz > SIGFPE.PC.73ceed83.STACK.d7d8808dd.CODE.1.ADDR.0x73ceed83.INSTR.idiv___%r8d.fuzz > SIGSEGV.PC.4bd833.STACK.18b2dd10ac.CODE.1.ADDR.0xa.INSTR.movzwl_0xa(%rax),%ecx.fuzz > SIGSEGV.PC.4be46b.STACK.1aba63653d.CODE.1.ADDR.(nil).INSTR.movzbl_(%rcx,%rdx,1),%ecx.fuzz > SIGSEGV.PC.5704be.STACK.5c9a551.CODE.1.ADDR.0x7aaf0e08.INSTR.callq__0xfff3c6e2.fuzz > SIGSEGV.PC.5704be.STACK.5c9a551.CODE.1.ADDR.0x7efcecd8.INSTR.callq__0xfff3c6e2.fuzz > SIGSEGV.PC.5704be.STACK.5c9a551.CODE.1.ADDR.0x7f48eff8.INSTR.callq__0xfff3c6e2.fuzz > SIGSEGV.PC.5704be.STACK.5c9a551.CODE.1.ADDR.0x7f54e258.INSTR.callq__0xfff3c6e2.fuzz > SIGSEGV.PC.5704be.STACK.5c9a551.CODE.1.ADDR.0x7f60c128.INSTR.callq__0xfff3c6e2.fuzz > SIGSEGV.PC.5704be.STACK.5c9a551.CODE.1.ADDR.0x7f60d498.INSTR.callq__0xfff3c6e2.fuzz > SIGSEGV.PC.5704be.STACK.5c9a551.CODE.1.ADDR.0x7f60d4a8.INSTR.callq__0xfff3c6e2.fuzz > SIGSEGV.PC.5704be.STACK.5c9a551.CODE.1.ADDR.0x7f60daa8.INSTR.callq__0xfff3c6e2.fuzz > SIGSEGV.PC.5704be.STACK.5c9a551.CODE.1.ADDR.0x7f60db58.INSTR.callq__0xfff3c6e2.fuzz > SIGSEGV.PC.5704be.STACK.5c9a551.CODE.1.ADDR.0x7f6429a8.INSTR.callq__0xfff3c6e2.fuzz > SIGSEGV.PC.5947b5.STACK.1b0df30f87.CODE.1.ADDR.(nil).INSTR.movzbl_(%rcx,%rdx,1),%ecx.fuzz > SIGSEGV.PC.7fffefe7314e.STACK.18f3cc3594.CODE.1.ADDR.(nil).INSTR.movdqu_%xmm8,(%rdi,%rcx,1).fuzz This list is not very useful. Please provide at least backtraces (with the necessary -dbg packages installed). > I think some of them can be security issues (that's why they are not linked > in this email). > I want to handle such test cases to some trusted maintainers of Mplayer and > avoid spamming the > bug tracker. I already ask upstream > (http://permalink.gmane.org/gmane.comp.video.mplayer.devel/64515) > and they told me that mplayer 1.1 is unsupported, so i'm re-testing for the > last cve revision. I suspect that most the the issues you found are not even bugs in mplayer, but rather Libav, which is used in Ubuntu 14.04. We've switched back to FFmpeg recently and I suspect most/all of the issues you found don't affect it. Please test your samples with mplayer/ffmpeg from Debian unstable/testing or Ubuntu xenial. Best regards, Andreas ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
