Buffer Overflow vulnerability in giflib v.5.2.2 allows a remote attacker to cause a denial of service via the EGifGCBToExtension overwriting an existing Graphic Control Extension block without validating its allocated size.

Giflib contains a double-free vulnerability that is the result of a shallow copy in GifMakeSavedImage and incorrect error handling. The conditions needed to trigger this vulnerability are difficult but may be possible.

Heap-based Buffer Overflow vulnerability in openEuler giflib on Linux. This vulnerability is associated with program files gif2rgb.C.

This issue affects giflib: through 5.2.2.

Hello Bernhard,

On 09.04.25 23:23, Bernhard Rosenkränzer wrote: On Wednesday, April 09, 2025 23:11 CEST, Sebastian Pipping <sebastian () pipping org> wrote: https://github.com/openwrt/packages/issues/26277 Except for https://sourceforge.net/p/giflib/bugs/179/, all the issues seem to be in gif2rgb, which is, according to the giflib maintainer, "old and crappy code", and TBH, other than as a no-dependency test tool for giflib, it is fairly useless (just use ImageMagick or a similar tool to do the gif to rgb conversion). Simply removing the gif2rgb tool is probably an acceptable solution.

I would like to note that gif2rgb is currently shipped with e.g. Ubuntu [2] and so just dropping that tool will break something somewhere.

On a side note ImageMagick (7.1.1.38) seems to ignore logical screen size (section "18. Logical Screen Descriptor" of the spec [3]) in GIF files:

# file maxsize.gif maxsize.gif: GIF image data, version 89a, 65535 x 65535 ^^^^^^^^^^^^^ # magick maxsize.gif maxsize.png

# file maxsize.png maxsize.png: PNG image data, 1 x 1, 8-bit gray+alpha, non-interlaced ^^^^^ Either I misunderstand the GIF spec or ImageMagick goes against the spec and mis-converts this image. (I tried other sizes to be sure it's not an integer overflow issue but intention.) So ImageMagick so far would not be my goto for GIF. Happy to learn what I'm missing.

So far I'm personally in favor of collaborative repair rather than removal. I'm probably biased because sibling tool gifbuild already proved useful to me.

Best

Sebastian

[1] https://github.com/openela-main/giflib/blob/el9/SPECS/giflib.spec [2] https://packages.ubuntu.com/oracular/amd64/giflib-tools/filelist [3] https://www.w3.org/Graphics/GIF/spec-gif89a.txt

On Wednesday, April 09, 2025 23:11 CEST, Sebastian Pipping <sebastian () pipping org> wrote: https://github.com/openwrt/packages/issues/26277 Except for https://sourceforge.net/p/giflib/bugs/179/, all the issues seem to be in gif2rgb, which is, according to the giflib maintainer, "old and crappy code", and TBH, other than as a no-dependency test tool for giflib, it is fairly useless (just use ImageMagick or a similar tool to do the gif to rgb conversion). Simply removing the gif2rgb tool is probably an acceptable solution.

ttyl bero

A quick note that there is more to giflib than just CVE-2025-31344:

Duplication of CVEs, officially fixed versus de-facto still vulnerable in more than one case, another CVE also upcoming (not mine)… I created a quick summary of what I know at…

https://github.com/openwrt/packages/issues/26277

…if you're interested.

Best, Sebastian

Hi  Hanno,

We have noticed your report on this issue. But because the code snippet of the same issue exists in multiple code branches, so I think this issue is not fixed completely.

For the current CVE-2025-31344, Bernhard has submitted a patch: https://github.com/OpenMandrivaAssociation/giflib/blob/master/giflib-5.2.2-cve-2025-31344.patch. I think this patch works for the one we reported.

Best Regards, Yajie Li

On Monday, April 07, 2025 15:15 CEST, 李亚杰 <liyajie () openeuler sh> wrote: Affected Versions: - giflib 5.2.2 and below

Description: In the function DumpScreen2RGB of the giflib software, an attempt is made to access the color map through ColorMapEntry. The size of ColorMap is 6 bytes (from 0x602000000030 to 0x602000000036). However, when accessing ColorMap->Colors[GifRow[j]], the value of GifRow[j] exceeds the actual number of colors stored. Thanks for the disclosure. Since there doesn't seem to be a proposed patch yet, here's mine: https://github.com/OpenMandrivaAssociation/giflib/blob/master/giflib-5.2.2-cve-2025-31344.patch

ttyl bero

On Mon, 07 Apr 2025 21:15:25 +0800 李亚杰 <liyajie () openeuler sh> wrote: In the function DumpScreen2RGB of the giflib software, an attempt is made to access the color map through ColorMapEntry. The size of ColorMap is 6 bytes (from 0x602000000030 to 0x602000000036). However, when accessing ColorMap->Colors[GifRow[j]], the value of GifRow[j] exceeds the actual number of colors stored. The address pointed to by ColorMapEntry, 0x602000000039, goes beyond the allocated memory range for color data. As a result, accessing ColorMapEntry->Red leads to out-of-bounds access, causing a heap-buffer-overflow. I... think I reported this in 2016 already: https://sourceforge.net/p/giflib/bugs/79/

The bug was closed without a fix, yet with giflib's author claiming multiple times that it was fixed.

-- Hanno Böck https://hboeck.de/

Hi,

在 2025/4/7 21:15, 李亚杰 写道: Affected Versions: - giflib 5.2.2 and below

Description: In the function DumpScreen2RGB of the giflib software, an attempt is made to access the color map through ColorMapEntry. The size of ColorMap is 6 bytes (from 0x602000000030 to 0x602000000036). However, when accessing ColorMap->Colors[GifRow[j]], the value of GifRow[j] exceeds the actual number of colors stored. The address pointed to by ColorMapEntry, 0x602000000039, goes beyond the allocated memory range for color data. As a result, accessing ColorMapEntry->Red leads to out-of-bounds access, causing a heap-buffer-overflow.

Best Regards, Mingcong Bai> Credits: JiaXuan Song(m202372152 () hust edu cn) bale.cen(cenxianlong () huawei com)

Best Regards, Yajie Li

Affected Versions: - giflib 5.2.2 and below

Description: In the function DumpScreen2RGB of the giflib software, an attempt is made to access the color map through ColorMapEntry. The size of ColorMap is 6 bytes (from 0x602000000030 to 0x602000000036). However, when accessing ColorMap->Colors[GifRow[j]], the value of GifRow[j] exceeds the actual number of colors stored. The address pointed to by ColorMapEntry, 0x602000000039, goes beyond the allocated memory range for color data. As a result, accessing ColorMapEntry->Red leads to out-of-bounds access, causing a heap-buffer-overflow.

Credits: JiaXuan Song(m202372152 () hust edu cn) bale.cen(cenxianlong () huawei com)

Best Regards, Yajie Li

A heap buffer overflow vulnerability was found in giflib. A maliciously crafted gif file could cause the application to crash.

External references:

https://sourceforge.net/p/giflib/bugs/87/

Upstream fix:

https://sourceforge.net/p/giflib/code/ci/ea8dbc5786862a3e16a5acfa3d24e2c2f608cd88/

References:

http://bugs.fi/2016-03-gif2rgb.txt http://bugs.fi/media/afl/giflib/1.gif