#167 Heap-Buffer Overflow during Image Saving in DumpScreen2RGB Function at Line 321 of gif2rgb.c

[Norbert]

A heap-buffer overflow occurs during the image saving process within the DumpScreen2RGB function in gif2rgb.c, specifically between lines 321 and 323. This vulnerability manifests when a specially crafted GIF is processed for output. It is important to note that this issue is distinct from CVE-2022-28506. While the [5b74cd] commit effectively addresses CVE-2022-28506, it does not provide a resolution for this particular heap-buffer overflow problem. Consequently, even after applying the patch associated with CVE-2022-28506, the heap buffer overflow in question remains unmitigated.

The provided proof of concept (POC) successfully replicates the crash even if the 5b74cd commit (CVE-2022-28506) is applied.

POC crash on line 321 using the following -o output command

./giflib-5.2.1/gif2rgb -o out poc_crash

The POC_crash file is included.

[Norbert]

Assigned CVE number : CVE-2023-48161
POC crash:

[Eric S. Raymond]

This crah has been fixed. The tool now complains:

gif2rgb: Image is defective, decoding aborted

[Codres Bogdan]

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.

[Codres Bogdan]

THis patch is created based on the latest version ...

[Sebastian Pipping]

@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

[Sebastian Pipping]

@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

[Codres Bogdan]

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.

[Sebastian Pipping]

@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

[Codres Bogdan]

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.

[Codres Bogdan]

@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

[Sebastian Pipping]

@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 or (b) the code that still needs patching (starting line 330) for three-files mode. I feel relieved to finally have clarity on that.

[Sebastian Pipping]

@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?

[Codres Bogdan]

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
    #1 0x55c692693313 in GIF2RGB ../../giflib-5.1.4/util/gif2rgb.c:486
    #2 0x55c692693313 in main ../../giflib-5.1.4/util/gif2rgb.c:544
    #3 0x7fca18e4214a in __libc_start_main (/lib64/libc.so.6+0x2414a)
    #4 0x55c692693bc9 in _start (/usr/bin/gif2rgb+0x5bc9)

Address 0x6020000001e0 is a wild pointer.
SUMMARY: AddressSanitizer: heap-buffer-overflow ../../giflib-5.1.4/util/gif2rgb.c:323 in DumpScreen2RGB

With the same patch applied I do not have it anymore:

 gif2rgb -o out giflib_poc_CVE-2022-28506

gif2rgb: Image is defective, decoding aborted

Bogdan

[Sebastian Pipping]

@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