Menu

#23 heap-buffer-overflow /home/hsalo/src/potrace-1.15/src/bitmap.h:148 bm_dup

v1.0_(example)
closed
None
9
2017-09-02
2017-08-06
Henri Salo
No

There is heap-buffer-overflow in 1.15 release aswell. I'm not sure if this is a new case or incomplete fix for previous issue. Seems to reproduce also with different output formats.

/home/hsalo/builds/potrace/1.15/bin/potrace -o /dev/null potrace-1.15-heap-buffer-overflow-bm_dup.sample
=================================================================
==8530==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60200000efd0 at pc 0x4749e8 bp 0x7fff2a4ac990 sp 0x7fff2a4ac988
READ of size 8 at 0x60200000efd0 thread T0
    #0 0x4749e7 in bm_dup /home/hsalo/src/potrace-1.15/src/bitmap.h:148
    #1 0x4749e7 in bm_to_pathlist /home/hsalo/src/potrace-1.15/src/decompose.c:470
    #2 0x458bbc in potrace_trace /home/hsalo/src/potrace-1.15/src/potracelib.c:76
    #3 0x40afbc in process_file /home/hsalo/src/potrace-1.15/src/main.c:1108
    #4 0x405e63 in main /home/hsalo/src/potrace-1.15/src/main.c:1256
    #5 0x7f1118924b44 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b44)
    #6 0x409f8c (/home/hsalo/builds/potrace/1.15/bin/potrace+0x409f8c)

0x60200000efd1 is located 0 bytes to the right of 1-byte region [0x60200000efd0,0x60200000efd1)
allocated by thread T0 here:
    #0 0x7f111921e885 in calloc (/usr/lib/x86_64-linux-gnu/libasan.so.1+0x54885)
    #1 0x413962 in bm_new /home/hsalo/src/potrace-1.15/src/bitmap.h:121
    #2 0x413962 in bm_readbody_pnm /home/hsalo/src/potrace-1.15/src/bitmap_io.c:168
    #3 0x413962 in bm_read /home/hsalo/src/potrace-1.15/src/bitmap_io.c:135

SUMMARY: AddressSanitizer: heap-buffer-overflow /home/hsalo/src/potrace-1.15/src/bitmap.h:148 bm_dup
Shadow bytes around the buggy address:
  0x0c047fff9da0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff9db0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff9dc0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff9dd0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff9de0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
=>0x0c047fff9df0: fa fa fa fa fa fa fa fa fa fa[01]fa fa fa 00 02
  0x0c047fff9e00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff9e10: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff9e20: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff9e30: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff9e40: 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
==8530==ABORTING
1 Attachments

Discussion

  • Peter Selinger

    Peter Selinger - 2017-08-06

    Henri, I have been unable to reproduce this particular bug. What compiler options are you using? I used these steps:

    ./configure
    make CADD="-Wall -fsanitize=address"
    ./src/potrace -o /dev/null potrace-1.15-heap-buffer-overflow-bm_dup.sample

    and it is not reproducing it with potrace 1.15 (or 1.14). In either case I get the expected output "invalid ppm file". The same compiler option does reproduce your previous bug 22. Are you sure you attached the correct file?

    Thanks, -- Peter

     
  • Henri Salo

    Henri Salo - 2017-08-07

    Thanks for quick reply. I'll check this tomorrow.

     
  • Henri Salo

    Henri Salo - 2017-08-12

    I can only reproduce this after building the sofware with american fuzzy lop fuzzer. I'm not sure about the reason.

     
  • Henri Salo

    Henri Salo - 2017-08-28

    You can close this issue.

     
  • Henri Salo

    Henri Salo - 2017-08-28

    1.15 with ./configure && make -j

    valgrind --leak-check=full --show-leak-kinds=all ./src/potrace -o /dev/null ~/potrace-1.15-heap-buffer-overflow-bm_dup.sample
    ==15482== Memcheck, a memory error detector
    ==15482== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
    ==15482== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
    ==15482== Command: ./src/potrace -o /dev/null /home/afl/potrace-1.15-heap-buffer-overflow-bm_dup.sample
    ==15482== 
    potrace: /home/afl/potrace-1.15-heap-buffer-overflow-bm_dup.sample: file format error: invalid ppm file
    ==15482== 
    ==15482== HEAP SUMMARY:
    ==15482==     in use at exit: 1,218 bytes in 4 blocks
    ==15482==   total heap usage: 4 allocs, 0 frees, 1,218 bytes allocated
    ==15482== 
    ==15482== 10 bytes in 1 blocks are still reachable in loss record 1 of 4
    ==15482==    at 0x4C28C20: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
    ==15482==    by 0x53D2989: strdup (strdup.c:42)
    ==15482==    by 0x401E63: dopts (main.c:773)
    ==15482==    by 0x401E63: main (main.c:1155)
    ==15482== 
    ==15482== 72 bytes in 1 blocks are still reachable in loss record 2 of 4
    ==15482==    at 0x4C28C20: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
    ==15482==    by 0x4136EA: potrace_param_default (potracelib.c:38)
    ==15482==    by 0x401646: dopts (main.c:472)
    ==15482==    by 0x401646: main (main.c:1155)
    ==15482== 
    ==15482== 568 bytes in 1 blocks are still reachable in loss record 3 of 4
    ==15482==    at 0x4C28C20: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
    ==15482==    by 0x53BB00C: __fopen_internal (iofopen.c:73)
    ==15482==    by 0x402634: my_fopen_write (main.c:1008)
    ==15482==    by 0x402634: main (main.c:1242)
    ==15482== 
    ==15482== 568 bytes in 1 blocks are still reachable in loss record 4 of 4
    ==15482==    at 0x4C28C20: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
    ==15482==    by 0x53BB00C: __fopen_internal (iofopen.c:73)
    ==15482==    by 0x4026C4: my_fopen_read (main.c:1000)
    ==15482==    by 0x4026C4: main (main.c:1251)
    ==15482== 
    ==15482== LEAK SUMMARY:
    ==15482==    definitely lost: 0 bytes in 0 blocks
    ==15482==    indirectly lost: 0 bytes in 0 blocks
    ==15482==      possibly lost: 0 bytes in 0 blocks
    ==15482==    still reachable: 1,218 bytes in 4 blocks
    ==15482==         suppressed: 0 bytes in 0 blocks
    ==15482== 
    ==15482== For counts of detected and suppressed errors, rerun with: -v
    ==15482== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
    
     
  • Peter Selinger

    Peter Selinger - 2017-09-02

    OK, I'm closing this bug. It is normal for the program to have some memory unfreed when exiting with an error message.

     
  • Peter Selinger

    Peter Selinger - 2017-09-02
    • status: open --> closed
     

Log in to post a comment.