#1146076 graphicsmagick: decomposing three or more frames with +adjoin aborts with double free or corruption

Package:
graphicsmagick
Source:
graphicsmagick
Description:
collection of image processing tools
Submitter:
Alexis Bienvenüe
Date:
2026-08-31 19:11:01 UTC
Severity:
normal
Tags:
#1146076#5
Date:
2026-08-29 15:11:08 UTC
From:
To:
Dear Maintainer,

The GraphicsMagick command fails when decomposing a (three or more) multiple
frames tiff image to multiple tiff images. For example:

gm convert -size 10x10 xc:black image1.tif
gm convert image1.tif image1.tif image1.tif image.tif
gm identify image.tif
gm convert image.tif +adjoin image_%04d.tif

leads to the output:

image.tif[0] TIFF 10x10+0+0 DirectClass 1-bit 860 0.000u 0m:0.000005s
image.tif[1] TIFF 10x10+0+0 DirectClass 1-bit 860 0.000u 0m:0.000039s
image.tif[2] TIFF 10x10+0+0 DirectClass 1-bit 860 0.000u 0m:0.000033s
double free or corruption (out)
gm convert: abort due to signal 6 (SIGABRT) "Abort"...
Aborted

even if the output images image_0000.tif, image_0001.tif and image_0002.tif are
properly generated.

This runs with no error when image.tif contains only two frames, and when
requesting a jpg output image_%04d.jpg

These commands run with no error with version
libgraphicsmagick-q16-3t64=1.4+really1.3.45+hg17696-1

Thanks,
Alexis Bienvenüe.
#1146076#10
Date:
2026-08-29 16:46:34 UTC
From:
To:
I am able to reproduce this. It appears to be peculiar to writing to the
TIFF writer since I tried several other output formats and the problem
did not happen.

The issue appears to be related to the I/O 'blob' reference count which
results in destroying an underlying blob which was already destroyed.

This is towards the end of

    valgrind --tool=memcheck --leak-check=summary --read-var-info=yes --error-exitcode=2 --track-origins=yes --num-callers=12 --quiet

on the command

    gm convert -debug blob image.tif +adjoin image_%04d.tif

11:37:38 0:0.474968  0.470u 3758172 blob.c/DestroyBlob/1209/Blob:
   Destroy blob (ref counted): image 0x9fe3d20, blob 0xa01a060, ref 1, filename "image_0001.tif"
11:37:38 0:0.475144  0.470u 3758172 blob.c/DestroyBlob/1226/Blob:
     Destroy blob (real): image 0x9fe3d20, blob 0xa01a060, ref 0, filename "image_0001.tif"
11:37:38 0:0.475434  0.470u 3758172 blob.c/CloseBlob/957/Blob:
   Closing FileStream blob: image 0x9fe3d20, blob 0xa01a060, ref 0
11:37:38 0:0.475595  0.470u 3758172 blob.c/CloseBlob/961/Blob:
   Blob wrote 293 bytes, read 0 bytes
==3758172== Syscall param write(buf) points to unaddressable byte(s)

Bob
#1146076#15
Date:
2026-08-30 15:25:36 UTC
From:
To:
This bug was introduced by Mercurial changeset 17920:6834ca8851c9 on Tue
Jan 13 10:37:56 2026:

changeset:   17920:6834ca8851c9
user:        Bob Friesenhahn <bfriesen@GraphicsMagick.org>
date:        Tue Jan 13 10:37:56 2026 -0600
files:       ChangeLog VisualMagick/installer/inc/version.isx
fuzzing/README.txt magick/blob.c magick/version.h www/ChangeLog.html
description:
magick/blob.c: Restore use of externally allocated stdio vbuf.

I will investigate further.

Bob
#1146076#20
Date:
2026-08-31 18:52:02 UTC
From:
To:
This issue is fixed by Mercurial commit 18143:8d4bbb4eb1b9. There was
some wrong code in tiff.c which did not match other similar code. 
However, I am not sure why the blob I/O code became more fragile given
misuse due to the changeset I mentioned earlier.

There needs to be another GM release soon give that at five security
issues have been addressed since the last release.

Bob
#1146076#25
Date:
2026-08-31 19:02:12 UTC
From:
To:
Le lundi 31 août 2026 à 13:52 -0500, Bob Friesenhahn a écrit :

Great! Thanks for this quick fix.

Alexis.