#157 An OutofMemory-Exception or Memory Leak in gif2rgb

[Ivan G]

System Env

Ubuntu 16.04(server)

Kernel: Linux ubuntu 5.0.5-050005-generic #201903271212 SMP Wed Mar 27 16:14:07 UTC 2019 x8664 x8664 x8664 GNU/Linux

gif2rgb 5.14

gcc version 7.5.0 (Ubuntu 7.5.0-3ubuntu1~18.04)

Configure

export CFLAGS="-g -fsanitize=address -fno-omit-frame-pointer" \
export LDFLAGS="-g -fsanitize=address -fno-omit-frame-pointer"

Command

./gif2rgb @@

Output

[ 4389.814860] Call Trace:
[ 4389.815518]  dump_stack+0x63/0x8a
[ 4389.815529]  dump_header+0x54/0x308
[ 4389.815540]  ? sched_clock+0x9/0x10
[ 4389.815549]  oom_kill_process.cold.29+0xb/0x1d6
[ 4389.815558]  out_of_memory+0x1bc/0x480
[ 4389.815568]  __alloc_pages_slowpath+0xb68/0xea0
[ 4389.815578]  __alloc_pages_nodemask+0x2c4/0x2e0
[ 4389.815589]  alloc_pages_current+0x81/0xe0
[ 4389.815599]  __page_cache_alloc+0x6a/0xa0
[ 4389.815609]  filemap_fault+0x403/0x8a0
[ 4389.815619]  ? xas_load+0xc/0x80
[ 4389.815628]  ? xas_find+0x157/0x190
[ 4389.815637]  ? filemap_map_pages+0x84/0x380
[ 4389.815647]  ext4_filemap_fault+0x31/0x44
[ 4389.815657]  __do_fault+0x3c/0x130
[ 4389.815667]  __handle_mm_fault+0xe4b/0x1280
[ 4389.815677]  ? __switch_to_asm+0x34/0x70
[ 4389.815687]  handle_mm_fault+0xe1/0x210
[ 4389.815696]  __do_page_fault+0x23a/0x4c0
[ 4389.815706]  do_page_fault+0x2e/0xe0
[ 4389.815715]  ? page_fault+0x8/0x30
[ 4389.815723]  page_fault+0x1e/0x30
[ 4389.815743] RIP: 0033:0x560d4760fed8
[ 4389.815755] Code: Bad RIP value.
[ 4389.815763] RSP: 002b:000000c420251cb0 EFLAGS: 00010283
[ 4389.815771] RAX: 0000560d491fcde0 RBX: 0000000000000001 RCX: 0000560d48a716c0
[ 4389.815780] RDX: 0000000000000018 RSI: 40442b34b36c38f7 RDI: 000000c420413970
[ 4389.815788] RBP: 000000c420251ce0 R08: 00007fff4c5c30b0 R09: 00007fff4c5c3080
[ 4389.815796] R10: 00000000000a1c8e R11: 0000000000001125 R12: 0000000000000000
[ 4389.815803] R13: 0000000000000018 R14: 0000000000000054 R15: 0000000000000100
[ 4389.815812] Mem-Info:
[ 4389.815823] active_anon:772579 inactive_anon:154814 isolated_anon:0
                active_file:14 inactive_file:19 isolated_file:0
                unevictable:0 dirty:0 writeback:0 unstable:0
                slab_reclaimable:9443 slab_unreclaimable:19149
                mapped:21 shmem:1 pagetables:4096 bounce:0
                free:21609 free_pcp:0 free_cma:0
[ 4389.815832] Node 0 active_anon:3090316kB inactive_anon:619256kB active_file:56kB inactive_file:76kB unevictable:0kB isolated(anon):0kB isolated(file):0kB mapped:84kB dirty:0kB writeback:0kB shmem:4kB shmem_thp: 0kB shmem_pmdmapped: 0kB anon_thp: 0kB writeback_tmp:0kB unstable:0kB all_unreclaimable? yes
[ 4389.815840] Node 0 DMA free:15620kB min:268kB low:332kB high:396kB active_anon:252kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB writepending:0kB present:15988kB managed:15904kB mlocked:0kB kernel_stack:0kB pagetables:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB
[ 4389.815850] lowmem_reserve[]: 0 2908 3843 3843 3843
[ 4389.815859] Node 0 DMA32 free:54632kB min:50932kB low:63664kB high:76396kB active_anon:2357544kB inactive_anon:618328kB active_file:112kB inactive_file:224kB unevictable:0kB writepending:0kB present:3129152kB managed:3039312kB mlocked:0kB kernel_stack:16kB pagetables:7248kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB
…….
[ 4389.815932] Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=1048576kB
[ 4389.815940] Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=2048kB
[ 4389.815948] 116 total pagecache pages
[ 4389.815957] 25 pages in swap cache
[ 4389.815965] Swap cache stats: add 1380554, delete 1380498, find 9812/20857
[ 4389.815973] Free swap  = 0kB
[ 4389.815981] Total swap = 998396kB
[ 4389.815989] 1048429 pages RAM
[ 4389.815996] 0 pages HighMem/MovableOnly
[ 4389.816004] 45224 pages reserved
[ 4389.816012] 0 pages cma reserved
[ 4389.816019] 0 pages hwpoisoned
[ 4389.816027] Tasks state (memory values in pages):
[ 4389.816035] [  pid  ]   uid  tgid total_vm      rss pgtables_bytes swapents oom_score_adj name
    ……
[ 4389.817580] [   1640]     0  1640     5702        1    90112      477             0 bash
[ 4389.817588] [   1901]     0  1901    24862        9   233472      238             0 sshd
[ 4389.817597] [   1956]     0  1956     5724       61    86016      439             0 bash
[ 4389.817607] [   2416]     0  2416 5368727780   926778 11087872   221610             0 gif2rgb
[ 4389.817615] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/user.slice,task=gif2rgb,pid=2416,uid=0
[ 4389.817643] Out of memory: Kill process 2416 (gif2rgb) score 918 or sacrifice child
[ 4389.819906] Killed process 2416 (gif2rgb) total-vm:21474911120kB, anon-rss:3707108kB, file-rss:4kB, shmem-rss:0kB
[ 4389.912731] oom_reaper: reaped process 2416 (gif2rgb), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB

[Eric S. Raymond]

This is not an interesting bug. The gif2rgb code is ancient and crappy, there is a warning on its manual pasge that malforned GIfs can crash it.

Please don't bother pointing out the 493rd bufg in this code unless you include a patch to fix it.

[Eric S. Raymond]

After I wrote my previous reply a submittee patch fixed this bug

esr@snark:~/WWW/giflib$ ./gif2rgb @@
GIF-LIB error: Failed to open given file.

[Ashish Patil]

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 really appreciated.

[Sebastian Pipping]

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

[Sebastian Pipping]

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 defining a huge logical screen (up to 65535x65535) and then to put just one single pixel into it (via an "Image Descriptor"). That image is far worse to gif2rgb because it makes it produce gigabytes of output and blocks one CPU at 100% for quite a while. Here's one way to create a file like that doesn't need a hex editor:

# python3 -c 'from PIL import Image; Image.new(size=(1, 1), mode="RGBA").save(format="GIF", fp=open("pixel.gif", "wb"))' 

# ./gifbuild -d -v pixel.gif | sed -r 's,^(screen (width|height) )1$,\165535,' | ./gifbuild > max_size.gif

# wc -c pixel.gif max_size.gif 
 51 pixel.gif
 49 max_size.gif
100 total

# file pixel.gif max_size.gif 
pixel.gif:    GIF image data, version 89a, 1 x 1
max_size.gif: GIF image data, version 89a, 65535 x 65535

# base64 max_size.gif
R0lGODlh/////4EAAAAAAAAAAAAAAAAAACH5BAEAAAAALAAAAAABAAEAAAICRAEAOw==

Playing with that file in Chromium shows they stop loading GIF files upwards of a certain size.
One fix could be to add a command line argument to gif2rgb to set a custom maximum size while loading (in uint32_t pixel count) and default to something similar to Chromium (https://stackoverflow.com/a/68219692).

What do you think?

CC @ctulhu