From ${URL} : Following Raphael's advice, i found some memory corruptions in JasPer 1.900 after a quick round of fuzzing of the regression tests of Openjpeg. A few interesting test cases are available here: https://zimbra.imag.fr/home/gustavo.grieco@...g.fr/Briefcase/Public/cases.tar.gz They are compressed to avoid easily crash programs like Nautilus and Firefox. All them can be verified using: jasper --input $filename --output-format pnm (tested in Ubuntu 14.04, 32-bit but it should work in other configurations) Additionally. sigsegv.jp2 crashes most of the programs using gdk-pixbuf like Firefox and Chrome (!). I report them this issue a few days ago and advise them to disable preview of jpeg images since Jasper is unmaintained and vulnerable. Mozilla developers are working hard trying to find a workaround to avoid use vulnerable code. On the other hand, Chromium developers dismissed this issue saying that they will wait the "upstream fix". I think the cause of such memory corruptions is uninitialized values, taken from the heap, as valgrind reports: ==15417== Memcheck, a memory error detector ==15417== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. ==15417== Using Valgrind-3.10.0.SVN and LibVEX; rerun with -h for copyright info ==15417== Command: jasper --input sigsegv.jp2 --output-format pnm ==15417== ==15417== Conditional jump or move depends on uninitialised value(s) ==15417== at 0x405EE3F: ??? (in /usr/lib/i386-linux-gnu/libjasper.so.1.0.0) ==15417== by 0x405F110: ??? (in /usr/lib/i386-linux-gnu/libjasper.so.1.0.0) ==15417== by 0x405E6FC: jpc_decode (in /usr/lib/i386-linux-gnu/libjasper.so.1.0.0) ==15417== by 0x4057805: jp2_decode (in /usr/lib/i386-linux-gnu/libjasper.so.1.0.0) ==15417== by 0x404BDAB: jas_image_decode (in /usr/lib/i386-linux-gnu/libjasper.so.1.0.0) ==15417== by 0x8048D78: ??? (in /usr/bin/jasper) ==15417== by 0x40B1A82: (below main) (libc-start.c:287) ==15417== Uninitialised value was created by a heap allocation ==15417== at 0x402A17C: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) ==15417== by 0x405127A: jas_malloc (in /usr/lib/i386-linux-gnu/libjasper.so.1.0.0) ==15417== by 0x4051323: jas_alloc2 (in /usr/lib/i386-linux-gnu/libjasper.so.1.0.0) ==15417== by 0x405C926: ??? (in /usr/lib/i386-linux-gnu/libjasper.so.1.0.0) ==15417== by 0x405E6FC: jpc_decode (in /usr/lib/i386-linux-gnu/libjasper.so.1.0.0) ==15417== by 0x4057805: jp2_decode (in /usr/lib/i386-linux-gnu/libjasper.so.1.0.0) ==15417== by 0x404BDAB: jas_image_decode (in /usr/lib/i386-linux-gnu/libjasper.so.1.0.0) ==15417== by 0x8048D78: ??? (in /usr/bin/jasper) ==15417== by 0x40B1A82: (below main) (libc-start.c:287) ==15417== ==15417== Conditional jump or move depends on uninitialised value(s) ==15417== at 0x405F06C: ??? (in /usr/lib/i386-linux-gnu/libjasper.so.1.0.0) ==15417== by 0x405F110: ??? (in /usr/lib/i386-linux-gnu/libjasper.so.1.0.0) ==15417== by 0x405E6FC: jpc_decode (in /usr/lib/i386-linux-gnu/libjasper.so.1.0.0) ==15417== by 0x4057805: jp2_decode (in /usr/lib/i386-linux-gnu/libjasper.so.1.0.0) ==15417== by 0x404BDAB: jas_image_decode (in /usr/lib/i386-linux-gnu/libjasper.so.1.0.0) ==15417== by 0x8048D78: ??? (in /usr/bin/jasper) ==15417== by 0x40B1A82: (below main) (libc-start.c:287) ==15417== Uninitialised value was created by a heap allocation ==15417== at 0x402A17C: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) ==15417== by 0x405127A: jas_malloc (in /usr/lib/i386-linux-gnu/libjasper.so.1.0.0) ==15417== by 0x4051323: jas_alloc2 (in /usr/lib/i386-linux-gnu/libjasper.so.1.0.0) ==15417== by 0x405C826: ??? (in /usr/lib/i386-linux-gnu/libjasper.so.1.0.0) ==15417== by 0x405E6FC: jpc_decode (in /usr/lib/i386-linux-gnu/libjasper.so.1.0.0) ==15417== by 0x4057805: jp2_decode (in /usr/lib/i386-linux-gnu/libjasper.so.1.0.0) ==15417== by 0x404BDAB: jas_image_decode (in /usr/lib/i386-linux-gnu/libjasper.so.1.0.0) ==15417== by 0x8048D78: ??? (in /usr/bin/jasper) ==15417== by 0x40B1A82: (below main) (libc-start.c:287) ==15417== @maintainer(s): after the bump, in case we need to stabilize the package, please let us know if it is ready for the stabilization or not.
The first upstream version that contains the fix for this bug is 1.900.10 The first fixed version in tree was 1.900.15 So it will be fixed in the next stabilization of jasper. I'm adding stable blocked because there are some things that seems to not work in the latest jasper regards multilib and gold/bfd
With version 2.0.12, can we drop the 1.9.X so that we can close this.
Arches and Maintainer(s), Thank you for your work. Added to an existing GLSA Request.
This issue was resolved and addressed in GLSA 201707-07 at https://security.gentoo.org/glsa/201707-07 by GLSA coordinator Thomas Deutschmann (whissi).