I suppose https://github.com/ImageMagick/ImageMagick/commit/f6242e725c819a69bee2a444f8e4a3c7718b2b3f
Fix it. If so plezse merge this bug with the other one régression about pdf Le 1 septembre 2016 00:38:34 GMT+02:00, Frank Heckenbach <f.heckenb...@fh-soft.de> a écrit : >> On Wed, Aug 31, 2016 at 8:42 AM, Bastien ROUCARIES >> <roucaries.bast...@gmail.com> wrote: >> >> > Patches are needed for a security point of view but it is likely a >> > problem of backport intereaction. >> > >> > Could you help by pin point the problem. >> > >> > as root install a few package needed for imagemagick compilation: >> > apt-get install git >> > apt-get build-dep imagemagick > >Just for my reference: >libbz2-dev libdjvulibre-dev libexif-dev libharfbuzz-dev >libharfbuzz-gobject0 libilmbase-dev libjasper-dev libjbig-dev >liblcms2-dev liblqr-1-0-dev liblzma-dev libopenexr-dev libpango1.0-dev >libperl-dev libtiff5-dev libtiffxx5 libwmf-dev pkg-kde-tools xsltproc > >> > as a user >> > git clone git://git.debian.org/git/collab-maint/imagemagick.git >> > cd imagemagick >> >> HERE run >> git checkout debian-patches/6.8.9.9-5+deb8u3 >> >> > git checkout debian-patches/6.8.9.9-5+deb8u4 > >So I ran both (first +deb8u3, then +deb8u4), right? >(Otherwise, +deb8u3 would be the same as in "good" below.) > >> > git bisect start >> > git bisect bad >> > git bissect good debian-patches/6.8.9.9-5+deb8u3 >> > >> > Once you have specified at least one bad and one good commit, git >> > bisect selects a commit in the middle of that range of history, >checks >> > it out, and outputs something similar to the following: >> > >> > Bisecting: 675 revisions left to test after this >(roughly 10 steps) >> > >> > You should now compile the checked-out version and test it. If >that >> > version works correctly, type. Compiling is done by typing >> > ./configure >> > make check > >That already gave an error (see test-suite.log). (I first ran make >with "-j16", then reran "make check" (but didn't rebuild) without >"-j", same result.) I'll be ignoring this (and further test-suite >errors I got while bisecting). > >> > you could run the command without installing by runing the >convert.sh wrapper >> > ./magick.sh convert geometry 40% tux.png tux-scaled-old.ppm >> > >> > if bad run >> > git bisect bad >> > and rerun compile and testing >> > if good run >> > git bisect good >> > >> > Some pointer could be found in man git bisect > >26d910675e0cd1b62e988139dba8eb11931260ac is the first bad commit >commit 26d910675e0cd1b62e988139dba8eb11931260ac >Author: Cristy <urban-warr...@imagemagick.org> >Date: Sat Jan 30 09:37:10 2016 -0500 > > Fix out of bound in quantum handling > > Bug: https://github.com/ImageMagick/ImageMagick/issues/105 >bug-ubuntu: >https://bugs.launchpad.net/ubuntu/+source/imagemagick/+bug/1539053 >origin: upstream, >https://github.com/ImageMagick/ImageMagick/commit/c4e63ad30bc42da691f2b5f82a24516dd6b4dc70 > bug-debian: https://bugs.debian.org/832506 > >:040000 040000 41e16d89455879892777d50135af38993b5be722 >e841bf15b62dee866b54eab729a93163d85aee68 M magick > >git diff 3e07cd10a9a2215c9edcc0c0e1541c125371cfbc >26d910675e0cd1b62e988139dba8eb11931260ac >shows that the change essentially replaced image->columns by >MagickMax(image->columns,image->rows) in several places. This might >explain why the bug only occurs with portrait. I see that some >callers of GetQuantumExtent() use its result as the length parameter >to ReadBlob and similar, so it seems strange to use the max of width >and height here. Others callers might use it for a work buffer where >this might be correct (and probably what the change was meant to >fix), but it might be necessary to separate those two cases. > >Frank -- Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.
