Giter Site home page Giter Site logo

posva / catimg Goto Github PK

View Code? Open in Web Editor NEW
1.3K 19.0 57.0 204 KB

🦦 Insanely fast image printing in your terminal

Home Page: http://posva.net/shell/retro/bash/2013/05/27/catimg

License: MIT License

Shell 1.59% C 98.04% CMake 0.37%
shell c imagemagick catimg terminal fun

catimg's People

Contributors

boretom avatar crazymerlyn avatar dmsc avatar fszymanski avatar ggustafsson avatar haroenv avatar neingeist avatar posva avatar shimmy1996 avatar sqlwwx avatar tianxiaogu avatar timgates42 avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

catimg's Issues

width (-w) handling depending on resolution

Hi,

I'm playing around with catimg (the c app, not the script) and don't fully understand the width (-w) parameter.

Especially I don't see why setting the resolution to 1 or 2 has an impact on the image width. The terminal width (tput cols) is the same in both scenarios, no? Is it supposed to behave like that?

/Thomas

Handle `.ico`

Could be nice to be able to do a catimg ./favicon.ico to see what it looks like :)

buffer overflow with corrupted ico

I found a heap-buffer-overflow when cat an image:
img.zip

=================================================================
==30486==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x619000000e82 at pc 0x0000005349b5 bp 0x7ffe3a703e70 sp 0x7ffe3a703e68
WRITE of size 1 at 0x619000000e82 thread T0
#0 0x5349b4 in stbi__bmp_load_cont /opt/catimg/src/stb_image.h:4748:25
#1 0x52a06f in stbi__ico_load /opt/catimg/src/stb_image.h:4867:15
#2 0x518fcf in stbi__xload_main /opt/catimg/src/sh_image.c:72:26
#3 0x51a553 in stbi_xload /opt/catimg/src/sh_image.c:92:18
#4 0x51b0c7 in img_load_from_file /opt/catimg/src/sh_image.c:188:30
#5 0x513847 in main /opt/catimg/src/catimg.c:115:9
#6 0x7fd91b062b96 in __libc_start_main /build/glibc-OTsEL5/glibc-2.27/csu/../csu/libc-start.c:310
#7 0x41b029 in _start (/opt/catimg/asan/bin/catimg+0x41b029)

0x619000000e82 is located 2 bytes to the right of 1024-byte region [0x619000000a80,0x619000000e80)
allocated by thread T0 here:
#0 0x4daee0 in malloc (/opt/catimg/asan/bin/catimg+0x4daee0)
#1 0x533785 in stbi__bmp_load_cont /opt/catimg/src/stb_image.h:4684:22
#2 0x52a06f in stbi__ico_load /opt/catimg/src/stb_image.h:4867:15
#3 0xff00000000000003 ()

SUMMARY: AddressSanitizer: heap-buffer-overflow /opt/catimg/src/stb_image.h:4748:25 in stbi__bmp_load_cont
Shadow bytes around the buggy address:
0x0c327fff8180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c327fff8190: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c327fff81a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c327fff81b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c327fff81c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0c327fff81d0:[fa]fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c327fff81e0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c327fff81f0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c327fff8200: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c327fff8210: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c327fff8220: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
==30486==ABORTING

24-bit colors vs Unicode should be orthogonal

For some reason, you assume 24-bit color codes are available when in Unicode mode, and 256 color otherwise. These capabilities are completely unrelated.

Not all terminals support 24-bit colors (https://gist.github.com/XVilka/8346728 -- non-fringe ones are Putty, Terminology and aterm; silently downconverting as xterm does is acceptable).

Non-Unicode is nearly extinct.

Too bad, neither of those imply the other.

monochrome Braille images

Here's an idea that might or might not be out of scope for your project:
by abusing the Braille range, it is possible to quadruple the resolution (2x4 pixels per character), at the cost of losing color. Even tricks we did in ZX-Spectrum days (finding the best ink/paper combination for a whole block) won't work as Braille pixels don't fill their whole space, so only ink can be reasonable changed, and that's probably not worth the effort.

On the other hand, black-and-white images would be useful for emails (esp. signatures), forum posts, etc -- such mediums don't allow colors.

I've did a variant for this for text rather than images in my braillefont.

Feature: option to fit vertically instead of horizontally

Hello and thanks for this very nice program!

It seems like big images are resized to fit the width of the console, but I would prefer to see the whole image without scrolling. Could you add a way to control this?

Alternatively, an option (or changing the default behaviour) to fit horizontally or vertically depending on the picture (i.e. use the most screen without overflowing) would also work for me.

Warnings when running sudo make install

When I run sudo make install, I get the following warnings:

Scanning dependencies of target catimg
[ 25%] Building C object CMakeFiles/catimg.dir/src/sh_color.c.o
[ 50%] Building C object CMakeFiles/catimg.dir/src/sh_utils.c.o
[ 75%] Building C object CMakeFiles/catimg.dir/src/catimg.c.o
/tmp/catimg/src/catimg.c: In function ‘main’:
/tmp/catimg/src/catimg.c:84:20: warning: the address of ‘supportsUTF8’ will always evaluate as ‘true’ [-Waddress]
                if (supportsUTF8)
                    ^
/tmp/catimg/src/catimg.c:113:41: warning: implicit declaration of function ‘usleep’ [-Wimplicit-function-declaration]
                                         usleep(img.delays[frame - 1] * 10000);
                                         ^
/tmp/catimg/src/catimg.c:101:17: warning: ignoring return value of ‘system’, declared with attribute warn_unused_result [-Wunused-result]
                 system("clear");
                 ^
[100%] Building C object CMakeFiles/catimg.dir/src/sh_image.c.o
In file included from /tmp/catimg/src/sh_image.c:3:0:
/tmp/catimg/src/stb_image.h: In function ‘stbi__gif_load_next’:
/tmp/catimg/src/stb_image.h:5653:84: warning: unused parameter ‘req_comp’ [-Wunused-parameter]
 static stbi_uc *stbi__gif_load_next(stbi__context *s, stbi__gif *g, int *comp, int req_comp)
                                                                                    ^
/tmp/catimg/src/sh_image.c: In function ‘stbi_xload’:
/tmp/catimg/src/sh_image.c:37:17: warning: suggest parentheses around assignment used as truth value [-Wparentheses]
                 while (gr->data = stbi__gif_load_next(&s, &g, channels, 4))
                 ^
/tmp/catimg/src/sh_image.c: In function ‘img_load_from_file’:
/tmp/catimg/src/sh_image.c:164:33: warning: ‘pixelSetter’ may be used uninitialized in this function [-Wmaybe-uninitialized]
                                 pixelSetter(&img->pixels[j + frame*w*h], ptr + i * sizeof(unsigned char) + offset);
                                 ^
Linking C executable bin/catimg
[100%] Built target catimg
Install the project...
-- Install configuration: "Release"
-- Installing: /usr/local/bin/catimg

I didn't know whether this is a problem, so I thought I'd report it - just to be on the safe side. Here's my uname -a:

Linux starbeamrainbowlabs.com 2.6.32-042stab111.12 #1 SMP Thu Sep 17 11:38:20 MSK 2015 x86_64 x86_64 x86_64 GNU/Linux

Incorrect colour output with zsh

I installed catimg using brew and added the plugin to oh-my-zsh. It works for the most part but the colours are wrong. I tested it using the test images in the repo and mewtwo looks like this:

Screen Shot 2019-03-14 at 3 48 39 PM

Is there some configuration change I need to make or is this an issue with the oh-my-zsh plugin?

Undefined behavior was detected in the source code.

catimg/src/stb_image.h:1571:24: error: The left operand in a bitwise left-shift is negative.
  Undefined behavior (UB-CEB4).
   see C11 section 6.5.7:4 http://rvdoc.org/C11/6.5.7
   see C11 section J.2:1 item 52 http://rvdoc.org/C11/J.2
   see CERT-C section INT13-C http://rvdoc.org/CERT-C/INT13-C
   see CERT-C section MSC15-C http://rvdoc.org/CERT-C/MSC15-C
   see MISRA-C section 8.1:3 http://rvdoc.org/MISRA-C/8.1
catimg/src/sh_image.c:4:0:
catimg/src/stb_image.h: In function ‘stbi__gif_load_next’:
catimg/src/stb_image.h:5752:84: warning: unused parameter ‘req_comp’ [-Wunused-parameter]
 static stbi_uc *stbi__gif_load_next(stbi__context *s, stbi__gif *g, int *comp, int req_comp)
                                                                                    ^
catimg/src/sh_utils.c: In function ‘read_stdin’:
catimg/src/sh_utils.c:45:14: warning: implicit declaration of function ‘fileno’ [-Wimplicit-function-declaration]
     int fd = fileno(stdin);
              ^
catimg/src/catimg.c:127:9: error: Incompatible pointer types in assignment or function call arguments.
  Constraint violation (CV-TEAS2).
   see C11 section 6.5.16.1:1 http://rvdoc.org/C11/6.5.16.1
   see CERT-C section MSC40-C http://rvdoc.org/CERT-C/MSC40-C
   see MISRA-C section 8.1:1 http://rvdoc.org/MISRA-C/8.1
catimg/src/catimg.c: In function ‘main’:
catimg/src/catimg.c:138:21: warning: implicit declaration of function ‘usleep’ [-Wimplicit-function-declaration]
                     usleep(img.delays[frame - 1] * 10000);
                     ^
catimg/src/sh_color.h:39:1: error: Identifier color_map declared with incompatible types in different translation units.
  Undefined behavior (UB-TIN1).
   see C11 section 6.2.7:2 http://rvdoc.org/C11/6.2.7
   see C11 section J.2:1 item 15 http://rvdoc.org/C11/J.2
   see CERT-C section DCL23-C http://rvdoc.org/CERT-C/DCL23-C
   see CERT-C section DCL40-C http://rvdoc.org/CERT-C/DCL40-C
   see MISRA-C section 8.1:3 http://rvdoc.org/MISRA-C/8.1
catimg/src/sh_color.h:39:1: error: Multiple external definitions for color_map.
  Undefined behavior (UB-TIN2).
   see C11 section 6.9:5 http://rvdoc.org/C11/6.9
   see C11 section J.2:1 item 84 http://rvdoc.org/C11/J.2
   see CERT-C section MSC15-C http://rvdoc.org/CERT-C/MSC15-C
   see MISRA-C section 8.5:1 http://rvdoc.org/MISRA-C/8.5
   see MISRA-C section 8.8:6 http://rvdoc.org/MISRA-C/8.8
   see MISRA-C section 8.1:3 http://rvdoc.org/MISRA-C/8.1
catimg/src/sh_color.h:41:1: error: Multiple external definitions for yuv_color_map.
  Undefined behavior (UB-TIN2).
   see C11 section 6.9:5 http://rvdoc.org/C11/6.9
   see C11 section J.2:1 item 84 http://rvdoc.org/C11/J.2
   see CERT-C section MSC15-C http://rvdoc.org/CERT-C/MSC15-C
   see MISRA-C section 8.5:1 http://rvdoc.org/MISRA-C/8.5
   see MISRA-C section 8.8:6 http://rvdoc.org/MISRA-C/8.8
   see MISRA-C section 8.1:3 http://rvdoc.org/MISRA-C/8.1

C version changes the proportion of the image

image

The above is C version and the below is the script version. The script version shows the correct proportion, but the C version makes the image shorter.

I am using Bash on Windows.

Here is the original image: original

Segmentation fault caused by null pointer exception

We found a segfault fault in your software. When the parameter of "history" malloc on line 6484 of stb_image.h i
s too large and returns 0, the memset on line 6492 will crash.

The relevant code that caused the error

  first_frame = 0; 
   if (g->out == 0) {
      if (!stbi__gif_header(s, g, comp,0))     return 0; // stbi__g_failure_reason set by stbi__gif_header
      g->out = (stbi_uc *) stbi__malloc(4 * g->w * g->h);
      g->background = (stbi_uc *) stbi__malloc(4 * g->w * g->h); 
      g->history = (stbi_uc *) stbi__malloc(g->w * g->h); 
      if (g->out == 0)                      return stbi__errpuc("outofmem", "Out of memory");

      // image is treated as "tranparent" at the start - ie, nothing overwrites the current background; 
      // background colour is only used for pixels that are not rendered first frame, after that "background"
      // color refers to teh color that was there the previous frame. 
      memset( g->out, 0x00, 4 * g->w * g->h ); 
      memset( g->background, 0x00, 4 * g->w * g->h ); // state of the background (starts transparent)
      memset( g->history, 0x00, g->w * g->h );        // pixels that were affected previous frame
      first_frame = 1; 
   } else {
      // second frame - how do we dispoase of the previous one?
      dispose = (g->eflags & 0x1C) >> 2; 
      pcount = g->w * g->h; 

      if ((dispose == 3) && (two_back == 0)) {
         dispose = 2; // if I don't have an image to revert back to, default to the old background
      }

      if (dispose == 3) { // use previous graphic
         for (pi = 0; pi < pcount; ++pi) {
            if (g->history[pi]) {
               memcpy( &g->out[pi * 4], &two_back[pi * 4], 4 ); 
            }
         }
      } else if (dispose == 2) { 
         // restore what was changed last frame to background before that frame; 
         for (pi = 0; pi < pcount; ++pi) {
            if (g->history[pi]) {
               memcpy( &g->out[pi * 4], &g->background[pi * 4], 4 ); 
            }
         }
      } else {
         // This is a non-disposal case eithe way, so just 
         // leave the pixels as is, and they will become the new background
         // 1: do not dispose
         // 0:  not specified.
      }

      // background is what out is after the undoing of the previou frame; 
      memcpy( g->background, g->out, 4 * g->w * g->h ); 
   }

We are the result of fuzzing test using gif, this is the poc we got crash:

00000000: 4749 4638 3961 2080 ffff ff03 0000 0000  GIF89a .........
00000010: ff00 00ff ff00 ffff ff21 f904 0000 0000  .........!......
00000020: 002c 0000 0000 2000 2000 0002 849c cfa9  .,.... . .......

Exceeding the valid memory range while parsing the GIF file's background

I've attached the file. Please download and check the file.
2021-05-17-08_03_20_0x4c61b6c1_0xb1c1261c.zip

==49150==ERROR: LeakSanitizer: SEGV on unknown address 0x7ffff6320000 (pc 0x55555555b07e bp 0x7fffffff5820 sp 0x7fffffff57c0 T0)
==49150==The signal is caused by a WRITE memory access.
#0 0x55555555b07e in memcpy /usr/include/x86_64-linux-gnu/bits/string_fortified.h:34
#1 0x55555555b07e in stbi__gif_load_next /home/ubuntu/tmp/catimg-2.7.0/src/stb_image.h:6581
#2 0x55555555b262 in stbi__xload_main /home/ubuntu/tmp/catimg-2.7.0/src/sh_image.c:29
#3 0x555555562cf4 in stbi__xload_main /home/ubuntu/tmp/catimg-2.7.0/src/sh_image.c:17
#4 0x555555562dc0 in stbi_xload /home/ubuntu/tmp/catimg-2.7.0/src/sh_image.c:106
#5 0x55555556309c in img_load_from_file /home/ubuntu/tmp/catimg-2.7.0/src/sh_image.c:202
#6 0x5555555565db in main /home/ubuntu/tmp/catimg-2.7.0/src/catimg.c:146
#7 0x7ffff73a30b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2)
#8 0x5555555569bd in _start (/home/ubuntu/tmp/catimg-2.7.0/bin/catimg+0x29bd)

LeakSanitizer can not provide additional info.
SUMMARY: LeakSanitizer: SEGV /usr/include/x86_64-linux-gnu/bits/string_fortified.h:34 in memcpy

[INVALID] Windows binary

Dear Eduardo,
Could you be so kind to generate .exe for the rest of us who are merely users w/o compiler?

Buffer Overflow in catimg

During my research, I have found a global-buffer-overflow in your program
"catimg". I've attached the crashing input. Find below the output of
AddressSanitizer:
crash_catimg

=================================================================
==20758==ERROR: AddressSanitizer: global-buffer-overflow on address 0x00000048e740 at pc 0x0000004688ed bp 0x7ffd66701c30 sp 0x7ffd66701c20
READ of size 4 at 0x00000048e740 thread T0
#0 0x4688ec in stbi__extend_receive /home/vincent/tmp/catimg/src/stb_image.h:1667
#1 0x4688ec in stbi__jpeg_decode_block /home/vincent/tmp/catimg/src/stb_image.h:1722
#2 0x4688ec in stbi__parse_entropy_coded_data /home/vincent/tmp/catimg/src/stb_image.h:2487
#3 0x4688ec in stbi__decode_jpeg_image /home/vincent/tmp/catimg/src/stb_image.h:2822
#4 0x4688ec in load_jpeg_image /home/vincent/tmp/catimg/src/stb_image.h:3314
#5 0x4688ec in stbi__jpeg_load /home/vincent/tmp/catimg/src/stb_image.h:3407
#6 0x46be5b in stbi__load_main /home/vincent/tmp/catimg/src/stb_image.h:941
#7 0x48845e in stbi__xload_main /home/vincent/tmp/catimg/src/sh_image.c:72
#8 0x48845e in stbi_xload /home/vincent/tmp/catimg/src/sh_image.c:92
#9 0x48845e in img_load_from_file /home/vincent/tmp/catimg/src/sh_image.c:188
#10 0x404637 in main /home/vincent/tmp/catimg/src/catimg.c:115
#11 0x7f16dfeda82f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
#12 0x404988 in _start (/home/vincent/tmp/catimg/bin/catimg+0x404988)

0x00000048e740 is located 32 bytes to the left of global variable 'stbi__bmask' defined in '/home/vincent/tmp/catimg/src/stb_image.h:1598:21' (0x48e760) of size 68
0x00000048e740 is located 0 bytes to the right of global variable 'stbi__jbias' defined in '/home/vincent/tmp/catimg/src/stb_image.h:1651:18' (0x48e700) of size 64
SUMMARY: AddressSanitizer: global-buffer-overflow /home/vincent/tmp/catimg/src/stb_image.h:1667 stbi__extend_receive
Shadow bytes around the buggy address:
0x000080089c90: f9 f9 f9 f9 00 00 00 00 00 00 00 00 00 00 00 00
0x000080089ca0: 00 00 00 00 f9 f9 f9 f9 00 00 00 00 00 00 00 00
0x000080089cb0: 00 00 00 00 00 00 00 04 f9 f9 f9 f9 00 00 00 00
0x000080089cc0: 00 00 00 00 00 00 00 00 00 00 00 04 f9 f9 f9 f9
0x000080089cd0: 00 00 00 00 00 00 00 00 00 07 f9 f9 f9 f9 f9 f9
=>0x000080089ce0: 00 00 00 00 00 00 00 00[f9]f9 f9 f9 00 00 00 00
0x000080089cf0: 00 00 00 00 04 f9 f9 f9 f9 f9 f9 f9 00 00 00 00
0x000080089d00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x000080089d10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x000080089d20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x000080089d30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Heap right redzone: fb
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack partial redzone: f4
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
==20758==ABORTING

Script not working on macos catalina

Distro: OS X 10.15.5
Kernel: Darwin
Terminal: xterm-256color iTerm.app

I have tried the script in bash and zsh and in both shells I have the same results, a blinking screen repeating the following lines many pages long, the token is the only different part in every line.
./catimg: line 77: ((: 64.2629%: syntax error: invalid arithmetic operator (error token is ".2629%")
./catimg: line 66: [: 63.3999%: integer expression expected
./catimg: line 77: ((: 63.3999%: syntax error: invalid arithmetic operator (error token is ".3999%")

segfault in stbi__getn

Download and unzip the attached file. Maybe a duplicate of #38.

7.zip

=================================================================
==22453==ERROR: AddressSanitizer: SEGV on unknown address 0x7ff9f2ecef30 (pc 0x7ffbf645b5e8 bp 0x7fff3111b6b0 sp 0x7fff3111ae38 T0)
==22453==The signal is caused by a WRITE memory access.
    #0 0x7ffbf645b5e7  /build/glibc-OTsEL5/glibc-2.27/string/../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:339
    #1 0x4e472d in __asan_memcpy /home/t/Projects/lldb-testing/llvm/projects/compiler-rt/lib/asan/asan_interceptors_memintrinsics.cc:23
    #2 0x5ae214 in stbi__getn /home/t/Projects/afl/fuzzing-experiments/subjects/catimg/src/stb_image.h:1273:10
    #3 0x5ae214 in stbi__tga_load /home/t/Projects/afl/fuzzing-experiments/subjects/catimg/src/stb_image.h:5012
    #4 0x5ae214 in stbi__load_main /home/t/Projects/afl/fuzzing-experiments/subjects/catimg/src/stb_image.h:975
    #5 0x556121 in stbi__xload_main /home/t/Projects/afl/fuzzing-experiments/subjects/catimg/src/sh_image.c:72:26
    #6 0x5bea05 in stbi_xload /home/t/Projects/afl/fuzzing-experiments/subjects/catimg/src/sh_image.c:92:18
    #7 0x5bea05 in img_load_from_file /home/t/Projects/afl/fuzzing-experiments/subjects/catimg/src/sh_image.c:188
    #8 0x52836c in main /home/t/Projects/afl/fuzzing-experiments/subjects/catimg/src/catimg.c:115:9
    #9 0x7ffbf63c1b96 in __libc_start_main /build/glibc-OTsEL5/glibc-2.27/csu/../csu/libc-start.c:310
    #10 0x41bbe9 in _start (/home/t/Projects/afl/fuzzing-experiments/subjects/catimg/bin/catimg+0x41bbe9)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV /build/glibc-OTsEL5/glibc-2.27/string/../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:339 
==22453==ABORTING

Fix signal handler

  1. The data type "sig_atomic_t" should be reused for the variable "stop".
    • How do you think about to assign the value which will be passed to the function "intHandler" to it?
    • Should this variable checked more often so that the program can eventually be aborted quicker?
  2. Can the assignment "loops = loop" be deleted?

ASan global-buffer-overflow src/stb_image.h:1923 in stbi__extend_receive

PoC:
catimg-2018-10-01-001
Credit: Henri Salo
Tested in: ffa86ff

==28808==ERROR: AddressSanitizer: global-buffer-overflow on address 0x5562ea78f228 at pc 0x5562ea7319e9 bp 0x7fff9c764a00 sp 0x7fff9c7649f8
READ of size 4 at 0x5562ea78f228 thread T0
    #0 0x5562ea7319e8 in stbi__extend_receive /home/hsalo/src/catimg/src/stb_image.h:1923
    #1 0x5562ea7319e8 in stbi__jpeg_decode_block /home/hsalo/src/catimg/src/stb_image.h:1981
    #2 0x5562ea732b12 in stbi__parse_entropy_coded_data /home/hsalo/src/catimg/src/stb_image.h:2746
    #3 0x5562ea762607 in stbi__decode_jpeg_image /home/hsalo/src/catimg/src/stb_image.h:3145
    #4 0x5562ea762607 in load_jpeg_image /home/hsalo/src/catimg/src/stb_image.h:3597
    #5 0x5562ea762607 in stbi__jpeg_load /home/hsalo/src/catimg/src/stb_image.h:3754
    #6 0x5562ea762607 in stbi__load_main /home/hsalo/src/catimg/src/stb_image.h:992
    #7 0x5562ea788ffc in stbi__xload_main /home/hsalo/src/catimg/src/sh_image.c:86
    #8 0x5562ea788ffc in stbi_xload /home/hsalo/src/catimg/src/sh_image.c:106
    #9 0x5562ea788ffc in img_load_from_file /home/hsalo/src/catimg/src/sh_image.c:202
    #10 0x5562ea6f699b in main /home/hsalo/src/catimg/src/catimg.c:115
    #11 0x7f7d9c2612e0 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202e0)
    #12 0x5562ea6f6d69 in _start (/home/hsalo/src/catimg/bin/catimg+0x7d69)

0x5562ea78f228 is located 4 bytes to the right of global variable 'stbi__bmask' defined in '/home/hsalo/src/catimg/src/stb_image.h:1857:27' (0x5562ea78f1e0) of size 68
SUMMARY: AddressSanitizer: global-buffer-overflow /home/hsalo/src/catimg/src/stb_image.h:1923 in stbi__extend_receive
Shadow bytes around the buggy address:
  0x0aacdd4e9df0: 00 00 00 00 f9 f9 f9 f9 00 00 00 00 00 00 00 00
  0x0aacdd4e9e00: 00 00 00 00 00 00 00 04 f9 f9 f9 f9 00 00 00 00
  0x0aacdd4e9e10: 00 00 00 00 00 00 00 00 00 00 00 04 f9 f9 f9 f9
  0x0aacdd4e9e20: 00 00 00 00 00 00 00 00 00 07 f9 f9 f9 f9 f9 f9
  0x0aacdd4e9e30: 00 00 00 00 00 00 00 00 f9 f9 f9 f9 00 00 00 00
=>0x0aacdd4e9e40: 00 00 00 00 04[f9]f9 f9 f9 f9 f9 f9 00 00 00 00
  0x0aacdd4e9e50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0aacdd4e9e60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0aacdd4e9e70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0aacdd4e9e80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0aacdd4e9e90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07
  Heap left redzone:       fa
  Heap right redzone:      fb
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack partial redzone:   f4
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==28808==ABORTING

Potentially used usleep()

File: catimg/blob/master/src/catimg.c#L138

i.e
usleep(img.delays[frame - 1] * 10000);

The usleep() function suspends execution of the calling thread for (at least) usec microseconds.
The parameter you pass is a minimum time for sleeping. There's no guarantee that the thread will wake up after exactly the time specified. Given the specific dynamics of the scheduler, it may result in longer than expected delays.

Use nanosleep() instead.

Cheers!

heap buffer overflow in stbi__tga_load

Download and unzip the attached file.
57.zip

=================================================================
==24325==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6020000000f1 at pc 0x0000004e4ba2 bp 0x7fff46def830 sp 0x7fff46deefe0
READ of size 4 at 0x6020000000f1 thread T0
    #0 0x4e4ba1 in __asan_memcpy /home/t/Projects/lldb-testing/llvm/projects/compiler-rt/lib/asan/asan_interceptors_memintrinsics.cc:23
    #1 0x5b0505 in stbi__tga_load /home/t/Projects/afl/fuzzing-experiments/subjects/catimg/src/stb_image.h:5069:31
    #2 0x5b0505 in stbi__load_main /home/t/Projects/afl/fuzzing-experiments/subjects/catimg/src/stb_image.h:975
    #3 0x556121 in stbi__xload_main /home/t/Projects/afl/fuzzing-experiments/subjects/catimg/src/sh_image.c:72:26
    #4 0x5bea05 in stbi_xload /home/t/Projects/afl/fuzzing-experiments/subjects/catimg/src/sh_image.c:92:18
    #5 0x5bea05 in img_load_from_file /home/t/Projects/afl/fuzzing-experiments/subjects/catimg/src/sh_image.c:188
    #6 0x52836c in main /home/t/Projects/afl/fuzzing-experiments/subjects/catimg/src/catimg.c:115:9
    #7 0x7f8713ceab96 in __libc_start_main /build/glibc-OTsEL5/glibc-2.27/csu/../csu/libc-start.c:310
    #8 0x41bbe9 in _start (/home/t/Projects/afl/fuzzing-experiments/subjects/catimg/bin/catimg+0x41bbe9)

0x6020000000f1 is located 0 bytes to the right of 1-byte region [0x6020000000f0,0x6020000000f1)
allocated by thread T0 here:
    #0 0x4e5f17 in malloc /home/t/Projects/lldb-testing/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:146
    #1 0x5aeb0f in stbi__malloc /home/t/Projects/afl/fuzzing-experiments/subjects/catimg/src/stb_image.h:900:12
    #2 0x5aeb0f in stbi__tga_load /home/t/Projects/afl/fuzzing-experiments/subjects/catimg/src/stb_image.h:5021
    #3 0x5aeb0f in stbi__load_main /home/t/Projects/afl/fuzzing-experiments/subjects/catimg/src/stb_image.h:975
    #4 0x556121 in stbi__xload_main /home/t/Projects/afl/fuzzing-experiments/subjects/catimg/src/sh_image.c:72:26
    #5 0x5bea05 in stbi_xload /home/t/Projects/afl/fuzzing-experiments/subjects/catimg/src/sh_image.c:92:18
    #6 0x5bea05 in img_load_from_file /home/t/Projects/afl/fuzzing-experiments/subjects/catimg/src/sh_image.c:188
    #7 0x52836c in main /home/t/Projects/afl/fuzzing-experiments/subjects/catimg/src/catimg.c:115:9
    #8 0x7f8713ceab96 in __libc_start_main /build/glibc-OTsEL5/glibc-2.27/csu/../csu/libc-start.c:310

SUMMARY: AddressSanitizer: heap-buffer-overflow /home/t/Projects/lldb-testing/llvm/projects/compiler-rt/lib/asan/asan_interceptors_memintrinsics.cc:23 in __asan_memcpy
Shadow bytes around the buggy address:
  0x0c047fff7fc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c047fff7fd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c047fff7fe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c047fff7ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c047fff8000: fa fa fd fa fa fa fd fd fa fa fd fd fa fa fd fa
=>0x0c047fff8010: fa fa fd fa fa fa fd fa fa fa fd fd fa fa[01]fa
  0x0c047fff8020: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff8030: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff8040: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff8050: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff8060: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
  Shadow gap:              cc
==24325==ABORTING

Images do not properly scale vertically

Whenever I specify the -H flag scale with the height of my image. The complete image does not get shown. Like so:
2022-02-27-161936_514x596_scrot

This is more apparent when displaying gifs. Even with the -H flag, when displaying gifs since the gif is not scaled correctly, a jarring artifact can be noticed.

Other information:
An alternative to catimg, chafa properly resolves this issue and scales according with user prompts. For a workaround and temporary solution, users can use chafa.

catimg retired in Fedora repository

The package is scheduled for removal because it's 6+ weeks orphaned.

The original orphaned the package due to lack of time. I noticed that a spec file exists in this Git repo. This spec file contains a newer release than the one in the Fedora repo.

So this leaves me with a few questions.

  • Are you aware that this package was orphaned in Fedora?
  • If so, are you planning to adopt the package? Since you're actively maintaining a spec file.
  • The spec for version catimg 2.6 doesn't seem to build for Fedora 32 on x86_64: https://koji.fedoraproject.org/koji/taskinfo?taskID=50131810
  • Does it build for you?

I'm planning to take over the orphaned package. I'll troubleshoot the build errors soon, if I can solve it then I'll take ownership of the package. But I suspect that in the meantime the package will be removed from the repo's already.

Suggestion: Rotate image according to Orientation exif tag

Consider the following image (which has an orientation exif tag).

This way up!

  • A software reading this orientation tag (for instance, Firefox — just click on the image above) displays the text horizontally (with the correct orientation).
  • However, catimg (and the github inline preview) ignores this orientation tag, and displays it vertically.

It would be nice if catimg could rotate the image according to this orientation tag.

Thanks for your work!
-- Louis

preview in ssh

Hi, this is a really nice app.

I use gnome-terminal to display the images, and it works fine.
Moreover if I login into a remote shell (with ssh) and I start tmux (with byobu wrapper) the images are correctly displayed.

What's I don't understand is why it doesn't work in remote shell without tmux. The image makes no sense.
Screenshot from 2020-04-10 16-06-29

Are you aware of a problem with ssh, or - don't know - a required flag or environment variable to set?

thank you!

segfault on corrupted bmp files

Download and unzip the attached file.

catimg 42

42.zip

AddressSanitizer:DEADLYSIGNAL
=================================================================
==6640==ERROR: AddressSanitizer: SEGV on unknown address 0x7f34e2dfe8c0 (pc 0x0000006334c3 bp 0x7ffc1a40b340 sp 0x7ffc1a40ac60 T0)
==6640==The signal is caused by a READ memory access.
    #0 0x6334c2 in stbi__bmp_load_cont /home/t/Projects/afl/fuzzing-experiments/subjects/catimg/src/stb_image.h
    #1 0x58cce2 in stbi__bmp_load /home/t/Projects/afl/fuzzing-experiments/subjects/catimg/src/stb_image.h:4800:11
    #2 0x58cce2 in stbi__load_main /home/t/Projects/afl/fuzzing-experiments/subjects/catimg/src/stb_image.h:947
    #3 0x556121 in stbi__xload_main /home/t/Projects/afl/fuzzing-experiments/subjects/catimg/src/sh_image.c:72:26
    #4 0x5bea05 in stbi_xload /home/t/Projects/afl/fuzzing-experiments/subjects/catimg/src/sh_image.c:92:18
    #5 0x5bea05 in img_load_from_file /home/t/Projects/afl/fuzzing-experiments/subjects/catimg/src/sh_image.c:188
    #6 0x52836c in main /home/t/Projects/afl/fuzzing-experiments/subjects/catimg/src/catimg.c:115:9
    #7 0x7f3441323b96 in __libc_start_main /build/glibc-OTsEL5/glibc-2.27/csu/../csu/libc-start.c:310
    #8 0x41bbe9 in _start (/home/t/Projects/afl/fuzzing-experiments/subjects/catimg/bin/catimg+0x41bbe9)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV /home/t/Projects/afl/fuzzing-experiments/subjects/catimg/src/stb_image.h in stbi__bmp_load_cont
==6640==ABORTING

stack buffer-overflow in stbi__compute_huffman_codes

A stack buffer-overflow is detected. Attached is the test case that can reproduce the issue. You need to compile the catimg with ASAN.
sbo-1.zip

=================================================================
==16406==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffc9166dc0f at pc 0x0000005450e6 bp 0x7ffc9166d370 sp 0x7ffc9166d368
READ of size 1 at 0x7ffc9166dc0f thread T0
    #0 0x5450e5 in stbi__compute_huffman_codes /home/t/Projects/afl/fuzzing-experiments/subjects/catimg/src/stb_image.h:3708:29
    #1 0x5450e5 in stbi__parse_zlib /home/t/Projects/afl/fuzzing-experiments/subjects/catimg/src/stb_image.h:3803
    #2 0x5450e5 in stbi__do_zlib /home/t/Projects/afl/fuzzing-experiments/subjects/catimg/src/stb_image.h:3818
    #3 0x5eb136 in stbi_zlib_decode_malloc_guesssize_headerflag /home/t/Projects/afl/fuzzing-experiments/subjects/catimg/src/stb_image.h:3849:8
    #4 0x5eb136 in stbi__parse_png_file /home/t/Projects/afl/fuzzing-experiments/subjects/catimg/src/stb_image.h:4422
    #5 0x615cf6 in stbi__do_png /home/t/Projects/afl/fuzzing-experiments/subjects/catimg/src/stb_image.h:4472:8
    #6 0x615cf6 in stbi__png_load /home/t/Projects/afl/fuzzing-experiments/subjects/catimg/src/stb_image.h:4495
    #7 0x565630 in stbi__load_main /home/t/Projects/afl/fuzzing-experiments/subjects/catimg/src/stb_image.h
    #8 0x556121 in stbi__xload_main /home/t/Projects/afl/fuzzing-experiments/subjects/catimg/src/sh_image.c:72:26
    #9 0x5bea05 in stbi_xload /home/t/Projects/afl/fuzzing-experiments/subjects/catimg/src/sh_image.c:92:18
    #10 0x5bea05 in img_load_from_file /home/t/Projects/afl/fuzzing-experiments/subjects/catimg/src/sh_image.c:188
    #11 0x52836c in main /home/t/Projects/afl/fuzzing-experiments/subjects/catimg/src/catimg.c:115:9
    #12 0x7fc5fe7ffb96 in __libc_start_main /build/glibc-OTsEL5/glibc-2.27/csu/../csu/libc-start.c:310
    #13 0x41bbe9 in _start (/home/t/Projects/afl/fuzzing-experiments/subjects/catimg/bin/catimg+0x41bbe9)

Address 0x7ffc9166dc0f is located in stack of thread T0 at offset 2191 in frame
    #0 0x53d3ef in stbi__do_zlib /home/t/Projects/afl/fuzzing-experiments/subjects/catimg/src/stb_image.h:3812

  This frame has 4 object(s):
    [32, 2052) 'z_codelength.i.i' (line 3684)
    [2192, 2647) 'lencodes.i.i' (line 3685) <== Memory access at offset 2191 underflows this variable
    [2720, 2739) 'codelength_sizes.i.i' (line 3686)
    [2784, 2788) 'header.i.i' (line 3729)
HINT: this may be a false positive if your program uses some custom stack unwind mechanism, swapcontext or vfork
      (longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-buffer-overflow /home/t/Projects/afl/fuzzing-experiments/subjects/catimg/src/stb_image.h:3708:29 in stbi__compute_huffman_codes
Shadow bytes around the buggy address:
  0x1000122c5b30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1000122c5b40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1000122c5b50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1000122c5b60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1000122c5b70: 04 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2
=>0x1000122c5b80: f2[f2]00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1000122c5b90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1000122c5ba0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1000122c5bb0: 00 00 00 00 00 00 00 00 00 00 07 f2 f2 f2 f2 f2
  0x1000122c5bc0: f2 f2 f2 f2 00 00 03 f2 f2 f2 f2 f2 f8 f3 f3 f3
  0x1000122c5bd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
  Shadow gap:              cc
==16406==ABORTING

Show one text and one image side by side

I am trying to create something like neofetch does using bash.

I want to show one image on the right and one ascii art (using the cat << EOF myascii EOF command)
So that I can show a logo and a text on the other side.

I want to use it as my login welcome screen when I ssh some of my machines.

So I was able to show the ascii art by doing :

cat << EOF

 _____         _   
|_   _|       | |  
  | | ___  ___| |_ 
  | |/ _ \/ __| __|
  | |  __/\__ \ |_ 
  \_/\___||___/\__|
                   
                   

EOF

And showing my image using catimg myimage.png

However I try to show them both side by side. I tried using pr.
pr -m -t <(catimg) <(cat mytestfile.txt) but it doesn't work and it cuts my ascii art.

It's the same using the paste command.

Was anyone able to do it. If yes how ?
My ascii art is quiet long too so without it to be cutted it would be awesome.

Thanks for your help.

heap-buffer-overflow in img_load_from_data

Download and unzip the attached file.
184.zip

=================================================================
==30322==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6020000000f2 at pc 0x0000005bdf2d bp 0x7ffe187d5be0 sp 0x7ffe187d5bd8
WRITE of size 2 at 0x6020000000f2 thread T0
    #0 0x5bdf2c in img_load_from_data /home/t/Projects/afl/fuzzing-experiments/subjects/catimg/src/sh_image.c:174:52
    #1 0x5beadd in img_load_from_file /home/t/Projects/afl/fuzzing-experiments/subjects/catimg/src/sh_image.c:190:9
    #2 0x52836c in main /home/t/Projects/afl/fuzzing-experiments/subjects/catimg/src/catimg.c:115:9
    #3 0x7f5a606bab96 in __libc_start_main /build/glibc-OTsEL5/glibc-2.27/csu/../csu/libc-start.c:310
    #4 0x41bbe9 in _start (/home/t/Projects/afl/fuzzing-experiments/subjects/catimg/bin/catimg+0x41bbe9)

0x6020000000f2 is located 0 bytes to the right of 2-byte region [0x6020000000f0,0x6020000000f2)
allocated by thread T0 here:
    #0 0x4e5f17 in malloc /home/t/Projects/lldb-testing/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:146
    #1 0x5bd84e in img_load_from_data /home/t/Projects/afl/fuzzing-experiments/subjects/catimg/src/sh_image.c:145:51

SUMMARY: AddressSanitizer: heap-buffer-overflow /home/t/Projects/afl/fuzzing-experiments/subjects/catimg/src/sh_image.c:174:52 in img_load_from_data
Shadow bytes around the buggy address:
  0x0c047fff7fc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c047fff7fd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c047fff7fe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c047fff7ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c047fff8000: fa fa fd fa fa fa fd fd fa fa fd fd fa fa fd fa
=>0x0c047fff8010: fa fa fd fa fa fa fd fa fa fa fd fd fa fa[02]fa
  0x0c047fff8020: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff8030: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff8040: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff8050: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff8060: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
  Shadow gap:              cc
==30322==ABORTING

Corrupted GIF header causes null pointer dereference by failed allocation due to integer overflow

Hi,

I discovered a bug in catimg's GIF parsing code that causes a segmentation fault from a null pointer dereference. (Commit hash 70e6f5ef627240589378e0e9e527a197faa0acde.) The bug can be revealed by passing catimg a GIF with unusually large width and height header fields. Here are links to two GIFs to help with recreating the bug:

  1. GIF 1 is the original with which I found the bug. It's a fuzzed version of what was once a stock image.
  2. GIF 2 is a 10-byte-long file only containing the GIF header. It's much smaller and will also cause the same segmentation fault.

Stacktrace

Throwing this into GDB shows the failure is occurring at src/stb_image.h:6492, where a memset() is attempting to write to g->history.

image

g->history is NULL, which causes the segmentation fault.

image

Root Cause

After doing some digging, I found that the stbi__gif struct's w and h fields (signed 32-bit integers) are multiplied together to determine the size of a heap allocation made within stbi__gif_load_next():

g->out = (stbi_uc *) stbi__malloc(4 * g->w * g->h);
g->background = (stbi_uc *) stbi__malloc(4 * g->w * g->h);
g->history = (stbi_uc *) stbi__malloc(g->w * g->h);

When catimg parses GIF 1, the resulting w and h fields read from its GIF header are 65535 and 33023. Since w and h are signed ints, the results of the above three multiplications are:

// g->w = 65535
// g->h = 33023
g->out = (stbi_uc *) stbi__malloc(4 * g->w * g->h); // (4 * g->w * g->h) = 66714628
g->background = (stbi_uc *) stbi__malloc(4 * g->w * g->h); // (4 * g->w * g->h) = 66714628
g->history = (stbi_uc *) stbi__malloc(g->w * g->h); // (g->w * g->h) = -2130804991

The problem lies in the calculation for g->history. Because of the nature of signed integers, the product of 65535 and 33023 results in an integer too large for the 32-bit maximum. Thus, it wraps around to be interpreted as a large negative value. (Interestingly, this doesn't occur for g->out and g->background, because multiplying the large-negative by 4 causes another wrap-around back into the positives.)

This negative integer is passed into stbi__malloc(), which interprets the parameter as a size_t (an unsigned integer). Examining this in GDB shows that the negative number is interpreted as a huge positive integer:

image

As a result, the call to STBI_MALLOC() (which is a macro for malloc()) fails, returning a NULL pointer.

Exceeds maximum supported memory when processing gif with excessive w*h

I've attached the file. Please download and check the file.
2021-05-17-08_03_08_0x01bbb035_0xb1c1261c.zip

==18760==ERROR: LeakSanitizer: requested allocation size 0xffffffff80fe7f01 exceeds maximum supported size of 0x200000000
#0 0x7fe9eb6399c1 in __interceptor_malloc ../../../../src/libsanitizer/lsan/lsan_interceptors.cpp:54
#1 0x55ef228fdbf0 in stbi__malloc /home/ubuntu/catimg-2.7.0/src/stb_image.h:871
#2 0x55ef228fdbf0 in stbi__gif_load_next /home/ubuntu/catimg-2.7.0/src/stb_image.h:6484
#3 0x55ef228fe262 in stbi__xload_main /home/ubuntu/catimg-2.7.0/src/sh_image.c:29
#4 0x55ef22905cf4 in stbi__xload_main /home/ubuntu/catimg-2.7.0/src/sh_image.c:17
#5 0x55ef22905dc0 in stbi_xload /home/ubuntu/catimg-2.7.0/src/sh_image.c:106
#6 0x55ef2290609c in img_load_from_file /home/ubuntu/catimg-2.7.0/src/sh_image.c:202
#7 0x55ef228f95db in main /home/ubuntu/catimg-2.7.0/src/catimg.c:146
#8 0x7fe9eb3100b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2)

==18760==HINT: if you don't care about these errors you may set allocator_may_return_null=1
SUMMARY: LeakSanitizer: allocation-size-too-big ../../../../src/libsanitizer/lsan/lsan_interceptors.cpp:54 in __interceptor_malloc

Man page install

It would be good to add a man page install to the CMakeLists.txt file.

Double the resolution using unicode

By using the unicode character \u2580: ▀ and setting the background and the foreground colours, I can print two pixels in one space instead of one pixel in two spaces. This will double the resolution by printing twice as possible pixels given a certain width.

# use ^[[38;5;$colorindexm to change the foreground
# use ^[48;5;$colorindexm to change the background
printf '\033[38;5;1;48;5;2m\u2580\n'

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.