ERROR - Segmentation fault-TransformPaletteC<FileIO>::save

[EnchantedJohn]

The third Error is also Segmentation fault .I also use AFL tools The error is : Starting program: /home/lx/5_7/flif/flif/src/flif -e crashes/id:000010,sig:11,src:000110,op:havoc,rep:2 test5.flif --overwrite Warning: expected ".png", ".pnm" or ".pam" file name extension for input file, trying anyway...

Program received signal SIGSEGV, Segmentation fault. TransformPaletteC<FileIO>::save (this=, srcRanges=0xd05eb0, rac=...) at transform/palette_C.hpp:156 156 coder.write_int(0, srcRanges->max(p)-min-remaining, CPalette_vector[p][i]-min);

[EnchantedJohn]

(gdb) bt #0 TransformPaletteC<FileIO>::save (this=, srcRanges=0xd05eb0, rac=...) at transform/palette_C.hpp:156 #1 0x0000000000670199 in flif_encode<FileIO> (io=..., images=std::vector of length 1, capacity 1 = {...}, transDesc=std::vector of length 6, capacity 8 = {...}, options=...) at flif-enc.cpp:927 #2 0x000000000045ea4d in encode_flif (argc=, argv=0x7fffffffe318, images=std::vector of length 1, capacity 1 = {...}, options=...) at flif.cpp:344 #3 0x0000000000407c03 in main (argc=, argv=0x7fffffffe310) at flif.cpp:763

[EnchantedJohn]

(gdb) i r rax 0x0 0 rbx 0x0 0 rcx 0xd05130 13652272 rdx 0x3 3 rsi 0x0 0 rdi 0xd05eb0 13655728 rbp 0x7 0x7 rsp 0x7fffffff9b60 0x7fffffff9b60 r8 0x7fffffff9ba0 140737488329632 r9 0x34181a 3414042 r10 0x341819 3414041 r11 0x3 3 r12 0x0 0 r13 0xd05ee8 13655784 r14 0xd05eb0 13655728 r15 0x0 0 rip 0x597e80 0x597e80 <TransformPaletteC<FileIO>::save(ColorRanges const*, RacOutput24<FileIO>&) const+432> eflags 0x10202 [ IF RF ] cs 0x33 51 ss 0x2b 43 ds 0x0 0 es 0x0 0 fs 0x0 0 gs 0x0 0

[EnchantedJohn]

(gdb) x/8i $pc => 0x597e80 <TransformPaletteC<FileIO>::save(ColorRanges const*, RacOutput24<FileIO>&) const+432>: mov (%rsi,%r15,4),%r11d 0x597e84 <TransformPaletteC<FileIO>::save(ColorRanges const*, RacOutput24<FileIO>&) const+436>: mov (%r14),%rax 0x597e87 <TransformPaletteC<FileIO>::save(ColorRanges const*, RacOutput24<FileIO>&) const+439>: mov %r14,%rdi 0x597e8a <TransformPaletteC<FileIO>::save(ColorRanges const*, RacOutput24<FileIO>&) const+442>: mov 0x18(%rsp),%esi 0x597e8e <TransformPaletteC<FileIO>::save(ColorRanges const*, RacOutput24<FileIO>&) const+446>: sub %r12d,%r11d 0x597e91 <TransformPaletteC<FileIO>::save(ColorRanges const*, RacOutput24<FileIO>&) const+449>: mov %r11d,%ebp 0x597e94 <TransformPaletteC<FileIO>::save(ColorRanges const*, RacOutput24<FileIO>&) const+452>: callq 0x20(%rax) 0x597e97 <TransformPaletteC<FileIO>::save(ColorRanges const, RacOutput24<FileIO>&) const+455>: mov 0x40b0(%rsp),%rdi

[EnchantedJohn]

Warning: expected ".png", ".pnm" or ".pam" file name extension for input file, trying anyway... ==162752==ERROR: AddressSanitizer: heap-use-after-free on address 0x60300000eea0 at pc 0x5c36e2 bp 0x7fff2a55cb00 sp 0x7fff2a55caf8 WRITE of size 4 at 0x60300000eea0 thread T0 #0 0x5c36e1 in TransformPaletteC<FileIO>::process(ColorRanges const*, std::vector<Image, std::allocator<Image> > const&) transform/palette_C.hpp:130 #1 0x72e7d8 in bool flif_encode<FileIO>(FileIO&, std::vector<Image, std::allocator<Image> >&, std::vector<std::string, std::allocatorstd::string > const&, flif_options&) /home/lx/5_7/ASAN/FLIF-master/src/flif-enc.cpp:914 #2 0x4acaf5 in encode_flif(int, char**, std::vector<Image, std::allocator<Image> >&, flif_options&) /home/lx/5_7/ASAN/FLIF-master/src/flif.cpp:344 #3 0x408c14 in main /home/lx/5_7/ASAN/FLIF-master/src/flif.cpp:763 #4 0x7f130a216f44 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21f44) #5 0x49f14f (/home/lx/5_7/ASAN/FLIF-master/src/flif+0x49f14f)

0x60300000eea0 is located 16 bytes inside of 32-byte region [0x60300000ee90,0x60300000eeb0) freed by thread T0 here: #0 0x7f130ad635d7 in operator delete(void*) (/usr/lib/x86_64-linux-gnu/libasan.so.1+0x555d7) #1 0x50591a in __gnu_cxx::new_allocator<std::pair<int, int> >::deallocate(std::pair<int, int>, unsigned long) /usr/include/c++/4.9/ext/new_allocator.h:110 #2 0x50591a in std::allocator_traits<std::allocator<std::pair<int, int> > >::deallocate(std::allocator<std::pair<int, int> >&, std::pair<int, int>, unsigned long) /usr/include/c++/4.9/bits/alloc_traits.h:514 #3 0x50591a in std::_Vector_base<std::pair<int, int>, std::allocator<std::pair<int, int> > >::_M_deallocate(std::pair<int, int>*, unsigned long) /usr/include/c++/4.9/bits/stl_vector.h:178 #4 0x50591a in ~_Vector_base /usr/include/c++/4.9/bits/stl_vector.h:160 #5 0x50591a in ~vector /usr/include/c++/4.9/bits/stl_vector.h:425 #6 0x50591a in getRanges(Image const&) image/color_range.cpp:8

previously allocated by thread T0 here: #0 0x7f130ad6315f in operator new(unsigned long) (/usr/lib/x86_64-linux-gnu/libasan.so.1+0x5515f) #1 0x5076aa in __gnu_cxx::new_allocator<std::pair<int, int> >::allocate(unsigned long, void const*) /usr/include/c++/4.9/ext/new_allocator.h:104 #2 0x5076aa in std::allocator_traits<std::allocator<std::pair<int, int> > >::allocate(std::allocator<std::pair<int, int> >&, unsigned long) /usr/include/c++/4.9/bits/alloc_traits.h:488 #3 0x5076aa in std::_Vector_base<std::pair<int, int>, std::allocator<std::pair<int, int> > >::_M_allocate(unsigned long) /usr/include/c++/4.9/bits/stl_vector.h:170 #4 0x5076aa in void std::vector<std::pair<int, int>, std::allocator<std::pair<int, int> > >::_M_emplace_back_aux<std::pair<int, int> >(std::pair<int, int>&&) /usr/include/c++/4.9/bits/vector.tcc:412 #5 0x60200000eddf (+0xeddf)

SUMMARY: AddressSanitizer: heap-use-after-free transform/palette_C.hpp:130 TransformPaletteC<FileIO>::process(ColorRanges const*, std::vector<Image, std::allocator<Image> > const&) Shadow bytes around the buggy address: 0x0c067fff9d80: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c067fff9d90: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c067fff9da0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c067fff9db0: fa fa fa fa fa fa fa fa fa fa 00 00 00 00 fa fa 0x0c067fff9dc0: 00 00 00 00 fa fa 00 00 00 fa fa fa 00 00 00 00 =>0x0c067fff9dd0: fa fa fd fd[fd]fd fa fa 00 00 00 00 fa fa 00 00 0x0c067fff9de0: 00 07 fa fa fd fd fd fd fa fa 00 00 00 06 fa fa 0x0c067fff9df0: 00 00 00 00 fa fa 00 00 00 07 fa fa 00 00 00 06 0x0c067fff9e00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c067fff9e10: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c067fff9e20: 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 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 Contiguous container OOB:fc ASan internal: fe ==162752==ABORTING

[fgeek]

CVE-2018-10972 has been assigned for this issue (not requested by me).

[fgeek]

@EnchantedJohn include sample PoC file to this issue e.g. inside zip file.

[paride]

@jonsneyers FLIF is marked for autoremoval from Debian testing on Sat 09 Jun 2018 as this is considered a grave security issue...

[EnchantedJohn]

Thanks,guys,I will close this issue.

[fgeek]

Err what @EnchantedJohn. Why did you close this? This is not fixed.

[lgbaldoni]

What? The problem is still there on openSUSE Tumbleweed. If you don't plan on fixing this and the other security issues, please tell for I need to know how to proceed.

[fgeek]

@luigino I don't think that upstream has commented on this case. This should be reopened and fixed. I personally don't have skills to create a PR.

[lgbaldoni]

@fgeek right, sorry. @EnchantedJohn why did you close this?

[paride]

@jonsneyers If these issues (#503, #501, #509, #505, #504, #502 and others from @EnchantedJohn, plus #498) can't be addressed in the short term, I'll have to pull FLIF from Debian for the moment. The bugs are grave, and without fixing them the package won't make it to Debian testing (or stable) anyway. This doesn't mean the package can't be made part of Debian again in the future, after bringing it in better shape. I prefer to pull it before any other package sets a dependency on it.

[lgbaldoni]

@paride I don't think the developer cares. Anyway the package was pulled from openSUSE as well.