Activity for GIFLIB
-
Giuseppe Massaro posted a comment on discussion Help
I would like to discuss a possible security issue with giflib latest release. Is this still maintained? What is the process to report? thanks, Giuseppe
-
milahu posted a comment on ticket #132
possible solution: include a copy of the GifQuantizeBuffer function in downstream packages: https://github.com/coin3d/simage/pull/33 https://github.com/mono/libgdiplus/pull/575
-
possible solution: include a copy of the GifQuantizeBuffer function in downstream packages: https://github.com/coin3d/simage/pull/33 https://github.com/mono/libgdiplus/pull/575
-
Ritesh Raj Sarraf created ticket #34
Patch buffer overrun revealed by FORTIFY_SOURCE
-
Luke Griffioen created ticket #188
CVE-2024-45993
-
CVE-2025-31344
-
DARKNAVY created ticket #186
integer overflow in Icon2Gif
-
integer overflow in gifbg.c
-
uninitialized buffer in DumpScreen2RGB
-
out-of-bounds access in ModifyColorMap
-
out‐of‐bounds writes in Icon2Gif
-
out-of-bounds access in Gif2Icon
-
Tomasz Kłoczko created ticket #12
Create live github mirror or move git repo to github
-
Sandeep Wawdane posted a comment on ticket #179
@hartwork Thanks for asking! CVE Number Update: I’ve already submitted a request for a CVE ID for this issue. Got a confirmation email with a request ID, so it’s in process with the CVE Assignment Team. Patch Details: Patch Details: 1. Filename Check: Can be used basename() to strip out any directory paths from the input filename and blocks anything with .. or / to prevent path traversal tricks. 2. Safe File Creation: Temporary files are made in a secure way (like TempInto.XXXXXX) without using user...
-
Sebastian Pipping posted a comment on ticket #179
@thecybersandeep greetings, any updates on the topics of CVE number and/or availability of a patch? Thanks!
-
@bcodres thanks! At https://nvd.nist.gov/vuln/detail/CVE-2022-28506 I found… giflib_poc asan_report_giflib.png …now and I confirm your results. I think that means that we have four CVEs all being about the same thing… CVE-2022-28506 CVE-2023-48161 CVE-2024-45993 CVE-2025-31344 …, that the previous fix was incomplete, and that giflib-5.2.2-cve-2025-31344.patch completes it. Thanks for your help! Best, Sebastian
-
Codres Bogdan posted a comment on ticket #167
Hello @hartwork. I can confirm that with the POC for CVE-2022-28506 I have the issue in the same spot from DumpScreen2RGB as in CVE-2023-48161. gif2rgb -o out giflib_poc_CVE-2022-28506 ================================================================= ==402==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6020000001e0 at pc 0x55c692693314 bp 0x7ffdc4eb6300 sp 0x7ffdc4eb62f0 READ of size 1 at 0x6020000001e0 thread T0 #0 0x55c692693313 in DumpScreen2RGB ../../giflib-5.1.4/util/gif2rgb.c:323...
-
I checked Git masteragainst the two cases just now. The first case — command ./gif2rgb -s — I confirm as fixed (by commit 38e39296dea689c0ca972f6abb2e6cc180dfbd8f that is attributed to issue 153). The second case — command yes '' | ./gif2rgb -s 1 2 — fails with the exact same LeakSanitizer output on master of today (at 8bed392c280ad2c237e8bf1beca6f8f68f893e87).
-
@bcodres @mmuzila since related commit 368f28c0034ecfb6dd4b3412af4cc589a56e0611 says CVE-2022-28506 rather than CVE-2024-45993 I assume that CVE-2022-28506 is the same also?
-
@bcodres I agree — CVE-2024-45993 is the same! I just confirmed with a debugger that @mmuzila's file crashes/sample hits the same code path. What only now I realize is that the issue (likely) appeared fixed to some (or some of the time), because whether the user passes argument -1 or not — for single-file mode, in contrast to three-file mode — decides whether they run vulnerable code or not: they either run (a) the code with the fix from 368f28c0034ecfb6dd4b3412af4cc589a56e0611 for single-file mode...
-
The attached out-of-memory-expection-or-memory-leak.gif is 32 bytes in size and has a screen size of 65503x65503 in its header. While processing that file, gif2rgb allocates 65503x65503 (circa 4 GiB) rather early (in a nested loop) and then runs into error handling code due to the file's use of an invalid extension. Allocating later — delaying the allocation — may help this very case but it would not fix the core issue. If I am not mistaken GIF (https://www.w3.org/Graphics/GIF/spec-gif89a.txt) allows...
-
The attached out-of-memory-expection-or-memory-leak.gif is 32 bytes in size and has a screen size of 65503x65503 in its header. While processing that file, gif2rgb allocates 65503x65503 (circa 4 GiB) rather early (in a nested loop) and then runs into error handling code due to the file's use of an invalid extension. Allocating later — delaying the allocation — may help this very case but it would not fix the core issue. If I am not mistaken GIF (https://www.w3.org/Graphics/GIF/spec-gif89a.txt) allows...
-
The attached out-of-memory-expection-or-memory-leak.gif is 32 bytes in size and has a screen size of 65503x65503 in its header. While processing that file, gif2rgb allocates 65503x65503 (circa 4 GiB) rather early (in a nested loop) and then runs into error handling code due to the file's use of an invalid extension. Allocating later — delaying the allocation — may help this very case but it would not fix the core issue. If I am not mistaken GIF (https://www.w3.org/Graphics/GIF/spec-gif89a.txt) allows...
-
The attached out-of-memory-expection-or-memory-leak.gif is 32 bytes in size and has a screen size of 65503x65503 in its header. While processing that file, gif2rgb allocates 65503x65503 (circa 4 GiB) rather early (in a nested loop) and then runs into error handling code due to the file's use of an invalid extension. Allocating later — delaying the allocation — may help this very case but it would not fix the core issue. If I am not mistaken GIF (https://www.w3.org/Graphics/GIF/spec-gif89a.txt) allows...
-
The attached out-of-memory-expection-or-memory-leak.gif is 32 bytes in size and has a screen size of 65503x65503 in its header. While processing that file, gif2rgb allocates 65503x65503 (circa 4 GiB) rather early (in a nested loop) and then runs into error handling code due to the file's use of an invalid extension. Allocating later — delaying the allocation — may help this very case but it would not fix the core issue. If I am not mistaken GIF (https://www.w3.org/Graphics/GIF/spec-gif89a.txt) allows...
-
The attached out-of-memory-expection-or-memory-leak.gif is 32 bytes in size and has a screen size of 65503x65503 in its header. While processing that file, gif2rgb allocates 65503x65503 (circa 4 GiB) rather early (in a nested loop) and then runs into error handling code due to the file's use of an invalid extension. Allocating later — delaying the allocation — may help this very case but it would not fix the core issue. If I am not mistaken GIF (https://www.w3.org/Graphics/GIF/spec-gif89a.txt) allows...
-
@hartwork @esr I've found another duplicate of this bug. Is CVE-2024-45993 https://gitlab.com/mthandazo/project-pov I've tested without the patch with the sample from the link above and the error is the same. With the patch the issue is not reproducible anymore. gif2rgb -o out poc_CVE-2024-45993 gif2rgb: Image is defective, decoding aborted Bogdan
-
@thecybersandeep maybe I overlooked something — did you create a patch? Are you aware of a patch for this by anyone else?
-
Hello ! Yes, I can confirm that those 2 CVE's are the same. CVE-2025-31344 seems to be a duplicate of CVE-2023-48161.
-
@bcodres I confirm that the patch fixes the crash for the attached POC_crash file. As a consequence, this seems to mean that CVE-2023-48161 and CVE-2025-31344 are the very same thing, see https://github.com/OpenMandrivaAssociation/giflib/blob/master/giflib-5.2.2-cve-2025-31344.patch and https://seclists.org/oss-sec/2025/q2/25 . Can you confirm? CC @ctulhu
-
Hello @esr @hartwork Yes, I've doubled check the issue and indeed my initial patch solve some memory leaks. I've attached a new patch that should solve the issue. It's actually a similar patch as CVE-2022-28506 After applying the patch I do not have the issue anymore: gif2rgb -o out POC_crash_CVE-2023-48161 gif2rgb: Image is defective, decoding aborted Can you provide me feedback ? Bogdan.
-
bale.cen posted a comment on ticket #176
Yes, it's the same issue
-
@esr I just tried with vanilla giflib 5.2.2 (plus ASan plus UBSan a la make {O,LD}FLAGS='-fsanitize=address,undefined' CC=clang) and the POC_crash file attached by @tihanyin makes command ./gif2rgb -o out POC_crash crash with the same output as reported. This is not fixed, please fix. Thank you! CC @ctulhu
-
Hello @bale, FYI if I am not mistaken then this is the same thing that is being discussed as CVE-2025-31344 on https://seclists.org/oss-sec/2025/q2/21 at this very moment.
-
-Wformat-truncation likely pointing out an actual bug
-
@thecybersandeep perfect, thank you!
-
I used git bisect now and found that releases <5.1.5 are affected. Commit https://sourceforge.net/p/giflib/code/ci/ea8dbc5786862a3e16a5acfa3d24e2c2f608cd88/ has an apparent fix, issue #87 is related. CC @ctulhu
-
H @hartwork , I have already requested a CVE for this vulnerability. Once the CVE ID is assigned, I will update you and add it here.
-
@thecybersandeep are you aware of any CVE assigned to or requested for this?
-
Even with patch https://sourceforge.net/p/giflib/code/ci/ccbc956432650734c91acb3fc88837f7b81267ff/ applied, master seems to still use 5 GB of RAM/RSS to process that 32 bytes file before aborting with error GIF-LIB error: Wrong record type detected. So the issue seems unfixed to me. CC @ctulhu
-
@esr I just tried with vanilla giflib 5.2.2 (plus ASan plus UBSan a la make {O,LD}FLAGS='-fsanitize=address,undefined' CC=clang) and the POC_crash file attached by @tihanyin makes command gif2rgb -o out POC_crash crash with the same output as reported. This is not fixed, please fix. Thank you! CC @ctulhu
-
@bcodres the patched you attached — both the initial and the rebased one — only add three calls to free which I would expect to be able to fix a memory leak but not a buffer overflow. Am I missing something? Could you verify the patch files contains what you intended to share for a fix? Thank you! CC @ctulhu
-
@esr I just tried with vanilla giflib 5.2.2 (plus ASan plus UBSan a la make {O,LD}FLAGS='-fsanitize=address,undefined' CC=clang) and the POC_crash file attached by @bcodres makes command gif2rgb -o out POC_crash crash with the same output as reported. This is not fixed, please fix. Thank you! CC @ctulhu
-
Path Traversal vulnerability in giflib's gifinto utility allows creation of files in arbitrary directories due to insufficient validation of user-supplied filenames.
-
Benson Muite created merge request #18 on Code
Install libutils
-
Enable installation of libutils
-
sanyuefeiyu created ticket #178
long time no new version and can release a new version?
-
Michal Hlavinka created ticket #177
wrong pointer used in giftool getbool
-
Ashish Patil posted a comment on ticket #157
Hi I was wondering if there are any patch releases of giflib planned in the near future. V5.2.2 still has the bug reported in CVE-2021-40633 (https://nvd.nist.gov/vuln/detail/CVE-2021-40633) . I see that the fix for the same has been submitted and accepted into the main branch through this Merge Request (https://sourceforge.net/p/giflib/code/merge-requests/12/). The overall score of this CVE is 8.8 (High) and impacts Availability, Confidentiality, and Integrity. A patch release for this would be...
-
Incomplete fix for issue 159
-
J G Miller created ticket #173
installation of manual pages and html documentation
-
Daniel Macks posted a comment on ticket #172
That's solely based on the lack of sync between the two platforms and also between the linker and the dependencies list. But that fix causes FTBFS due to unresolved symbols when linking libutil.dylib: "_GifErrorString", referenced from: _PrintGifError in qprintf.o because qprintf.o is now only in libgif not libutil. If libutil is (as name suggests) utility functions and (as the Makefile behaves on all platforms) not actually install libutil publicly, should it be static-only on all platforms?
-
Incorrect object files in shared libutil on darwin
-
Martin Jansa created merge request #17 on Code
Makefile: fix typo in soname argument
-
Sebastian Koerner posted a comment on ticket #33
Prio is not 1 but very low. I failed to set it correctly.
-
Race-Condition on Install
-
Anonymous updated merge request #16
Fix #171 - Require ImageMagick Only for Building Giflib Website
-
Bobby Villaluz posted a comment on merge request #16
Please reject this merge request as the issue was already addressed by Avoid having an install-time dependency on convert(1)
-
Please disregard and close this issue as it was already addressed by Avoid having an install-time dependency on convert(1).
-
Anonymous created merge request #16 on Code
Fix #171 - Require ImageMagick Only for Building Giflib Website
-
ImageMagick required to build giflib on non-Darwin Platforms
-
Adam Sampson posted a comment on ticket #170
I ran into this as well, building with -D_FORTIFY_SOURCE=3 - it's because the snprintf calls in giftext.c that write into AsciiForm have the length set as 3 rather than 2. Here's a patch.
-
Uilian Ries created merge request #15 on Code
Add support for CMake
-
seb1282 created ticket #170
Tests failing on Ubuntu Noble, giftext buffer overflow
-
THis patch is created based on the latest version ...
-
Hello Eric ! Unfortunately, I still have this error even after I've applied this patch and some others. The fix for me was to free "Buffers". Please find attached the patch.
-
Eric S. Raymond committed [8bed39] on Code
Emphasize lossnessless.
-
Enable gif2rgb-regress.
-
More build recipe simplification.
-
Anonymous created merge request #14 on Code
Fix minor documentation errors
-
Simplify the test machinery.
-
Robustify against overly verbose gmake.
-
Shortenm some long lines.
-
Shorten a name in order to avoid problems when we reflow.
-
Correct typos, shoe=rten and fix version strings.
-
Move Gershon Elber's copyrights from strings to SPDX headers...
-
More through SPDXification.
-
NEWS update.
-
Improve cleanup of doc/
-
Tests are now fully TAPified.
-
More TAPification.
-
Integrate and TAPify gifinto test.
-
More TAPification.
-
Add a FIXME to testing.
-
Begin TAPification.
-
Andreas Metzler posted a comment on merge request #8
Updated by force-push.
-
GifQuantizeBuffer function prototype mismatch
-
Fix applied, thanks.
-
Address issue #169: GifQuantizeBuffer function prototype mismatch
-
NEW file correction.
-
GifQuantizeBuffer function prototype mismatch
-
Fabrice Fontaine posted a comment on merge request #7
Merge Request updated
-
A initial CMakeLists.txt for portable builds
-
I dislike CMake, and it is overcomplicated for this build.
-
fix for #157 An OutofMemory-Exception or Memory Leak in gif2rgb CVE-2021-40633
-
Clean up memory better at end of run (CVE-2021-40633)
-
Make it easier to control the build with environment variables.
1 >