[Pkg-gmagick-im-team] Bug#835650: Imagemagick regression pin point patch

Frank Heckenbach f.heckenbach at fh-soft.de
Wed Aug 31 22:38:34 UTC 2016


> On Wed, Aug 31, 2016 at 8:42 AM, Bastien ROUCARIES
> <roucaries.bastien at 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-warrior at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test-suite.log.bz2
Type: application/octet-stream
Size: 4719 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-gmagick-im-team/attachments/20160901/e68c6b16/attachment.obj>


More information about the Pkg-gmagick-im-team mailing list