Menu ▾ ▴

#181 Segfault in EAN Generator

2.0
closed
Harald Oehlmann
bug (2)
2024-02-27
2020-02-13
Christian Hartlage
No

Hi,
I set up fuzzing for the barcode generation and found a few bugs in different barcode generations. This Ticket is focussing on the EAN creation, because only a few ASCII characters input are enough to trigger the bug.

You can either input "55++15" into the qt-ui or use my reproducer.

This little reprocuder triggers the bug: 

#include <zint.h>
#include <string>

int main() {
  std::string input = "55++15";
  struct zint_symbol *my_symbol;my_symbol = ZBarcode_Create();

  my_symbol->symbology = BARCODE_EANX;
  ZBarcode_Encode_and_Buffer(my_symbol, (unsigned char *) input.c_str(), input.size() , 0);

  ZBarcode_Delete(my_symbol);

  return 0;
}

Link against the current libzint.so as generated by cmake and the segfault will occur.
When compiled with address sanitizer, the following stacktrace will be printed:

/home/c/.local/share/code-intelligence/projects/project-4905718a-4da1-11ea-bbe0-8c1645a161cb/libfuzzer/address/backend/upcean.c:331:24: runtime error: index -1 out of bounds for type 'const char *[4]'
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /home/c/.local/share/code-intelligence/projects/project-4905718a-4da1-11ea-bbe0-8c1645a161cb/libfuzzer/address/backend/upcean.c:331:24 in 
/home/c/.local/share/code-intelligence/projects/project-4905718a-4da1-11ea-bbe0-8c1645a161cb/libfuzzer/address/backend/upcean.c:331:24: runtime error: null pointer passed as argument 2, which is declared to never be null
/usr/include/string.h:122:14: note: nonnull attribute specified here
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /home/c/.local/share/code-intelligence/projects/project-4905718a-4da1-11ea-bbe0-8c1645a161cb/libfuzzer/address/backend/upcean.c:331:24 in 
AddressSanitizer:DEADLYSIGNAL
=================================================================
==18211==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x7f77850ea5a1 bp 0x7ffe4ef2c1f0 sp 0x7ffe4ef2b9a8 T0)
==18211==The signal is caused by a READ memory access.
==18211==Hint: address points to the zero page.
    #0 0x7f77850ea5a0  /build/glibc-OTsEL5/glibc-2.27/string/../sysdeps/x86_64/multiarch/strlen-avx2.S:59
    #1 0x47edaf in strcpy /tmp/final/llvm.src/projects/compiler-rt/lib/asan/asan_interceptors.cc:429:22
    #2 0x7f7786599893 in add_on /home/c/.local/share/code-intelligence/projects/project-4905718a-4da1-11ea-bbe0-8c1645a161cb/libfuzzer/address/backend/upcean.c:331:9
    #3 0x7f77865971cb in eanx /home/c/.local/share/code-intelligence/projects/project-4905718a-4da1-11ea-bbe0-8c1645a161cb/libfuzzer/address/backend/upcean.c:881:13
    #4 0x7f7786554046 in reduced_charset /home/c/.local/share/code-intelligence/projects/project-4905718a-4da1-11ea-bbe0-8c1645a161cb/libfuzzer/address/backend/library.c
    #5 0x7f7786549e1b in ZBarcode_Encode /home/c/.local/share/code-intelligence/projects/project-4905718a-4da1-11ea-bbe0-8c1645a161cb/libfuzzer/address/backend/library.c:1205:20
    #6 0x7f778655228f in ZBarcode_Encode_and_Buffer /home/c/.local/share/code-intelligence/projects/project-4905718a-4da1-11ea-bbe0-8c1645a161cb/libfuzzer/address/backend/library.c:1392:20
    #7 0x4c57c2 in main (/home/c/.local/share/code-intelligence/projects/project-4905718a-4da1-11ea-bbe0-8c1645a161cb/libfuzzer/address/demo/poc+0x4c57c2)
    #8 0x7f7784f7db96 in __libc_start_main /build/glibc-OTsEL5/glibc-2.27/csu/../csu/libc-start.c:310
    #9 0x41b6b9 in _start (/home/c/.local/share/code-intelligence/projects/project-4905718a-4da1-11ea-bbe0-8c1645a161cb/libfuzzer/address/demo/poc+0x41b6b9)

I will create bug reports for the other barcodes when I have some time in the next days. In order to trigger them the input needs to contain some non-printable characters so I don't think they are as significant as the EAN one.

Affected barcodes are AUSPOST family, CODEONE, DOTCODE, VIN and CODABLOCKF

Best regards,

Chris

Discussion

  • Robin Stuart

    Robin Stuart - 2020-02-15

    Hi Chris,

    Thank you for finding this and taking the time to let us know. I have added a check to the UPC/EAN code to throw an error if more than one + character is included in the input data.

    I look forward to seeing what else you find!

    Robin.

     

  • Christian Hartlage

    Christian Hartlage - 2020-02-16

    Hi Robin,
    Another bug, that I found in the Australian Post family of barcodes can be triggered when inputting the following byte sequence: 0x41 0x00 0x00 0x00, an uppercase A followed by 3 null bytes. This will lead to a heap buffer read overflow:

    ==11==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x611000004300 at pc 0x000000683a71 bp 0x7ffe2d708d80 sp 0x7ffe2d708d78
READ of size 4 at 0x611000004300 thread T0
SCARINESS: 27 (4-byte-read-heap-buffer-overflow-far-from-bounds)
    #0 0x683a70 in rs_encode /src/zint/backend/reedsol.c:135:62
    #1 0x5971f5 in rs_error /src/zint/backend/auspost.c:85:5
    #2 0x5971f5 in australia_post /src/zint/backend/auspost.c:224:5
    #3 0x55cbbf in reduced_charset /src/zint/backend/library.c:785:28
    #4 0x555dc4 in ZBarcode_Encode /src/zint/backend/library.c:1205:20
    #5 0x55b62f in ZBarcode_Encode_and_Buffer /src/zint/backend/library.c:1392:20
    #6 0x5543cc in LLVMFuzzerTestOneInput /src/zint/all_barcodes_fuzzer.cpp:52:3
    #7 0x45a021 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:556:15
    #8 0x459745 in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long, bool, fuzzer::InputInfo*, bool*) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:470:3
    #9 0x45bae7 in fuzzer::Fuzzer::MutateAndTestOne() /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:698:19
    #10 0x45c875 in fuzzer::Fuzzer::Loop(std::__Fuzzer::vector<fuzzer::SizedFile, fuzzer::fuzzer_allocator<fuzzer::SizedFile> >&) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:830:5
    #11 0x44a8f8 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:824:6
    #12 0x474722 in main /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:19:10
    #13 0x7f7e815a182f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
    #14 0x41dfb8 in _start (/out/all_barcodes_fuzzer+0x41dfb8)
     

  • Christian Hartlage

    Christian Hartlage - 2020-02-16

    If you want to support OSS-Fuzz integration, the static libary version needs to be integrated by you. For better conforming OSS-Fuzz rules you could also check in the fuzz target at a fitting location in the project itself (like libpng is doing here: https://github.com/glennrp/libpng/tree/libpng16/contrib/oss-fuzz).

    Zint might even be eligible for an integration reward by Google: https://opensource.googleblog.com/2017/05/oss-fuzz-five-months-later-and.html

    But I don't know exactly how they deem projects to be eligible.

    Best regards,
    Chris

     

    Last edit: Christian Hartlage 2022-03-23

  • Christian Hartlage

    Christian Hartlage - 2020-02-16

    CODABLOCKF crashes due to a read global buffer overflow with input 0x1c,0x1c,0x49

        #0 0x5ac022 in codablock /src/zint/backend/codablock.c:993:26
    #1 0x55d0f2 in reduced_charset /src/zint/backend/library.c:863:49
    #2 0x555dc4 in ZBarcode_Encode /src/zint/backend/library.c:1205:20
    #3 0x55b62f in ZBarcode_Encode_and_Buffer /src/zint/backend/library.c:1392:20
    #4 0x5543cc in LLVMFuzzerTestOneInput /src/zint/all_barcodes_fuzzer.cpp:52:3
    #5 0x45a021 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:556:15
    #6 0x459745 in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long, bool, fuzzer::InputInfo*, bool*) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:470:3
    #7 0x45bae7 in fuzzer::Fuzzer::MutateAndTestOne() /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:698:19
    #8 0x45c875 in fuzzer::Fuzzer::Loop(std::__Fuzzer::vector<fuzzer::SizedFile, fuzzer::fuzzer_allocator<fuzzer::SizedFile> >&) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:830:5
    #9 0x44a8f8 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:824:6
    #10 0x474722 in main /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:19:10
    #11 0x7f2d6eb1782f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
    #12 0x41dfb8 in _start (/out/all_barcodes_fuzzer+0x41dfb8)

    DOTCODE crashes due to a read-dynamic-stack-buffer-overflow with input 0x28,0x87,0x27:

        #0 0x658336 in binary /src/zint/backend/dotcode.c:447:9
    #1 0x658336 in dotcode_encode_message /src/zint/backend/dotcode.c:1005:24
    #2 0x658336 in dotcode /src/zint/backend/dotcode.c:1298:19
    #3 0x55cfcc in reduced_charset /src/zint/backend/library.c:861:46
    #4 0x555dc4 in ZBarcode_Encode /src/zint/backend/library.c:1205:20
    #5 0x55b62f in ZBarcode_Encode_and_Buffer /src/zint/backend/library.c:1392:20
    #6 0x5543cc in LLVMFuzzerTestOneInput /src/zint/all_barcodes_fuzzer.cpp:52:3
    #7 0x45a021 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:556:15
    #8 0x459745 in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long, bool, fuzzer::InputInfo*, bool*) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:470:3
    #9 0x45bae7 in fuzzer::Fuzzer::MutateAndTestOne() /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:698:19
    #10 0x45c875 in fuzzer::Fuzzer::Loop(std::__Fuzzer::vector<fuzzer::SizedFile, fuzzer::fuzzer_allocator<fuzzer::SizedFile> >&) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:830:5
    #11 0x44a8f8 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:824:6
    #12 0x474722 in main /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:19:10
    #13 0x7f220959482f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
    #14 0x41dfb8 in _start (/out/all_barcodes_fuzzer+0x41dfb8)
     

  • Christian Hartlage

    Christian Hartlage - 2020-02-19

    So, I debugged some of the crashes and it seems they only have potential to crash libzint when compiled with address sanitizer.

     

    Last edit: Christian Hartlage 2022-03-23

  • Harald Oehlmann

    Harald Oehlmann - 2020-03-03
    • assigned_to: Harald Oehlmann
     

  • Harald Oehlmann

    Harald Oehlmann - 2020-03-03

    Dear Christian,
    thank you for the repot. I just want to say, that examining the report is on my todo-List.

    Thank you,
    Harald

     

  • Nico Gunkel

    Nico Gunkel - 2020-03-12

    Dear Harald,
    we also fuzzed the zint library and found some more bugs. All files to reproduce the bugs are in the attachment and you can trigger every bug with the zint command line tool
    if you compile it with address sanitizer (-DZINT_SANITIZE=TRUE). All line numbers are from zint-2.7.1

    telepent.c - telepen()

    ./zint -b32 -i telepen-b32

=================================================================
==158358==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffd12619d60 at pc 0x7f5a1f0bed11 bp 0x7ffd12619af0 sp 0x7ffd12619298
WRITE of size 13 at 0x7ffd12619d60 thread T0
    #0 0x7f5a1f0bed10 in __interceptor_strcat /build/gcc/src/gcc/libsanitizer/asan/asan_interceptors.cc:384
    #1 0x55d978ddce76 in telepen /zint-2.7.1/backend/telepen.c:93
    #2 0x55d978d9f9ee in reduced_charset /zint-2.7.1/backend/library.c:761
    #3 0x55d978d9f9ee in extended_or_reduced_charset /zint-report/zint-2.7.1/backend/library.c:661
    #4 0x55d978da317e in ZBarcode_Encode /zint-2.7.1/backend/library.c:1205
    #5 0x55d978da9d45 in ZBarcode_Encode_File /zint-2.7.1/backend/library.c:1478
    #6 0x55d978d99127 in main /zint-2.7.1/frontend/main.c:733
    #7 0x7f5a1e36f022 in __libc_start_main (/usr/lib/libc.so.6+0x27022)
    #8 0x55d978d9b98d in _start (/zint-2.7.1/build-asan/frontend/zint+0x29398d)

Address 0x7ffd12619d60 is located in stack of thread T0 at offset 544 in frame
    #0 0x55d978ddcb5f in telepen /zint-2.7.1/backend/telepen.c:60

  This frame has 1 object(s):
    [32, 544) 'dest' (line 63) <== Memory access at offset 544 overflows this variable
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 /build/gcc/src/gcc/libsanitizer/asan/asan_interceptors.cc:384 in __interceptor_strcat
Shadow bytes around the buggy address:
  0x1000224bb350: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1000224bb360: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 00 00 00
  0x1000224bb370: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1000224bb380: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1000224bb390: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x1000224bb3a0: 00 00 00 00 00 00 00 00 00 00 00 00[f3]f3 f3 f3
  0x1000224bb3b0: f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00
  0x1000224bb3c0: ca ca ca ca 00 00 00 07 cb cb cb cb 00 00 00 00
  0x1000224bb3d0: 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 00
  0x1000224bb3e0: 00 f2 f2 f2 02 f2 00 00 00 00 00 00 00 00 00 00
  0x1000224bb3f0: 00 00 00 00 01 f3 f3 f3 f3 f3 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
==158358==ABORTING

    In telepen.c 63 char dest[512]; /*14 + 30 * 14 + 14 + 14 + 1 ~ 512 */ the dest array is too small because the biggest element in 41 static char *TeleTable[] is 16 byte.
    I think the best solution is to increase thedest[] buffer. (If I calculate it correct 111 char dest[1024]; should be large enough)

    library.c - ZBarcode_Encode()

    ./zint -i ZBarcode_Encode

=================================================================
==169091==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x602000000011 at pc 0x7fd5f40d02e1 bp 0x7ffd6fcbb900 sp 0x7ffd6fcbb0a8
READ of size 2 at 0x602000000011 thread T0
    #0 0x7fd5f40d02e0 in __interceptor_strlen /build/gcc/src/gcc/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:354
    #1 0x560f4ea5d8d7 in ZBarcode_Encode /zint-2.7.1/backend/library.c:995
    #2 0x560f4ea63d45 in ZBarcode_Encode_File /zint-2.7.1/backend/library.c:1478
    #3 0x560f4ea53127 in main /zint-2.7.1/frontend/main.c:733
    #4 0x7fd5f33c8022 in __libc_start_main (/usr/lib/libc.so.6+0x27022)
    #5 0x560f4ea5598d in _start (/zint-2.7.1/build-asan/frontend/zint+0x29398d)

0x602000000011 is located 0 bytes to the right of 1-byte region [0x602000000010,0x602000000011)
allocated by thread T0 here:
    #0 0x7fd5f4178b3a in __interceptor_malloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cc:144
    #1 0x560f4ea63c22 in ZBarcode_Encode_File /zint-2.7.1/backend/library.c:1457

SUMMARY: AddressSanitizer: heap-buffer-overflow /build/gcc/src/gcc/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:354 in __interceptor_strlen
Shadow bytes around the buggy address:
  0x0c047fff7fb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  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[01]fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff8010: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 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
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
==169091==ABORTING

    If you execute zint with an empty file you get a valid buffer of size zero in library.c 1457 buffer = (unsigned char *) malloc(fileLen * sizeof (unsigned char)); and then you call
    995 in_length = (int)ustrlen(source); on that buffer of size zero. Maybe you can return a ZINT_ERROR after 1444 fileLen = ftell(file); if the file size is zero.

    maxicode.c - maxi_text_process()

    ./zint -b57 -i maxicode-b57

/zint-2.7.1/backend/maxicode.c:433:41: runtime error: index 144 out of bounds for type 'int [144]'
/zint-2.7.1/backend/maxicode.c:433:41: runtime error: load of address 0x7ffdce6f7020 with insufficient space for an object of type 'int'
0x7ffdce6f7020: note: pointer points here
 3b 00 00 00  50 70 6f ce fd 7f 00 00  1e 00 00 00 00 00 00 00  21 37 7c 0b 8b 7f 00 00  ed 36 7c 0b
              ^
=================================================================
==169991==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffdce6f7020 at pc 0x5578d1a00da9 bp 0x7ffdce6f69c0 sp 0x7ffdce6f69b0
READ of size 4 at 0x7ffdce6f7020 thread T0
    #0 0x5578d1a00da8 in maxi_text_process /zint-2.7.1/backend/maxicode.c:433
    #1 0x5578d1a07027 in maxicode/zint-2.7.1/backend/maxicode.c:679
    #2 0x5578d190da20 in reduced_charset /zint-2.7.1/backend/library.c:857
    #3 0x5578d190da20 in extended_or_reduced_charset /zint-2.7.1/backend/library.c:661
    #4 0x5578d19139b5 in ZBarcode_Encode /zint-2.7.1/backend/library.c:1212
    #5 0x5578d1917d45 in ZBarcode_Encode_File /zint-2.7.1/backend/library.c:1478
    #6 0x5578d1907127 in main /zint-2.7.1/frontend/main.c:733
    #7 0x7f8b0aa13022 in __libc_start_main (/usr/lib/libc.so.6+0x27022)
    #8 0x5578d190998d in _start (/zint-2.7.1/build-asan/frontend/zint+0x29398d)

Address 0x7ffdce6f7020 is located in stack of thread T0 at offset 1440 in frame
    #0 0x5578d19f856f in maxi_text_process /zint-2.7.1/backend/maxicode.c:150

  This frame has 6 object(s):
    [32, 40) 'set15' (line 157)
    [64, 72) 'set12' (line 158)
    [96, 116) 'set12345' (line 159)
    [160, 736) 'set' (line 155)
    [864, 1440) 'character' (line 155) <== Memory access at offset 1440 overflows this variable
    [1568, 1579) 'substring' (line 429)
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 /zint-2.7.1/backend/maxicode.c:433 in maxi_text_process
Shadow bytes around the buggy address:
  0x100039cd6db0: f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 00 00 00 00
  0x100039cd6dc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x100039cd6dd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x100039cd6de0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x100039cd6df0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x100039cd6e00: 00 00 00 00[f2]f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2
  0x100039cd6e10: f2 f2 f2 f2 00 03 f3 f3 00 00 00 00 00 00 00 00
  0x100039cd6e20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x100039cd6e30: 00 00 00 00 f1 f1 f1 f1 00 00 00 04 f2 f2 f2 f2
  0x100039cd6e40: 04 f2 04 f2 00 04 f2 f2 00 07 f2 f2 00 07 f2 f2
  0x100039cd6e50: 00 00 00 06 f2 f2 f2 f2 00 00 00 06 f2 f2 f2 f2
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
==169991==ABORTING

    I think the problem is this part of the code in maxicode.c

        150 static int maxi_text_process(int mode, unsigned char source[], int length, int eci) {
    151     /* This code doesn't make use of [Lock in C], [Lock in D]
    152     and [Lock in E] and so is not always the most efficient at
    153     compressing data, but should suffice for most applications */
    154
    155     int set[144], character[144], i, j, done, count, current_set;

      ...

    443             character[i + 5] = (value & 0x3f);
    444
    445             i += 6;
    446             for (j = i; j < 140; j++) {
    447                 set[j] = set[j + 3];
    448                 character[j] = character[j + 3];
    449             }
    450             length -= 3;
    451         } else {
    452             i++;
    453         }
    454     } while (i <= 143);

    in line 454 you check i <= 143 but in line 443 you access character[i + 5] this overflows if i >= 139

    code1.c - c1_encode()

    ./zint -b141 -i c1_encode-b141

=================================================================
==170204==ERROR: AddressSanitizer: dynamic-stack-buffer-overflow on address 0x7ffdac05ffe7 at pc 0x55b0b56d03d2 bp 0x7ffdac056be0 sp 0x7ffdac056bd0
READ of size 1 at 0x7ffdac05ffe7 thread T0
    #0 0x55b0b56d03d1 in c1_encode /zint-2.7.1/backend/code1.c:445
    #1 0x55b0b56d1f24 in code_one /zint-2.7.1/backend/code1.c:1414
    #2 0x55b0b558d5d4 in reduced_charset /zint-2.7.1/backend/library.c:847
    #3 0x55b0b558d5d4 in extended_or_reduced_charset /zint-2.7.1/backend/library.c:661
    #4 0x55b0b559117e in ZBarcode_Encode /zint-2.7.1/backend/library.c:1205
    #5 0x55b0b5597d45 in ZBarcode_Encode_File /zint-2.7.1/backend/library.c:1478
    #6 0x55b0b5587127 in main /zint-2.7.1/frontend/main.c:733
    #7 0x7f983dfa1022 in __libc_start_main (/usr/lib/libc.so.6+0x27022)
    #8 0x55b0b558998d in _start (/zint-2.7.1/build-asan/frontend/zint+0x29398d)

Address 0x7ffdac05ffe7 is located in stack of thread T0 at offset 36855 in frame
    #0 0x55b0b56d1a2f in code_one /zint-2.7.1/backend/code1.c:1187

  This frame has 13 object(s):
    [48, 108) 'data' (line 1203)
    [144, 204) 'ecc' (line 1203)
    [240, 340) 'ecc' (line 1307)
    [384, 504) 'stream' (line 1204)
    [544, 704) 'data' (line 1307)
    [768, 992) 'elreg' (line 1202)
    [1056, 1316) 'stream' (line 1308)
    [1392, 1692) 'sub_ecc' (line 1406)
    [1760, 2520) 'sub_data' (line 1406)
    [2656, 5056) 'ecc' (line 1405)
    [5184, 11184) 'data' (line 1405)
    [11440, 19840) 'stream' (line 1407)
    [20096, 36416) 'datagrid' (line 1190) <== Memory access at offset 36855 overflows this variable
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: dynamic-stack-buffer-overflow /zint-2.7.1/backend/code1.c:445 in c1_encode
Shadow bytes around the buggy address:
  0x100035803fa0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x100035803fb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x100035803fc0: 00 00 00 00 00 00 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3
  0x100035803fd0: f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3
  0x100035803fe0: f3 f3 f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00
=>0x100035803ff0: 00 00 00 00 ca ca ca ca 00 00 00 05[cb]cb cb cb
  0x100035804000: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1
  0x100035804010: 00 00 00 f2 f2 f2 02 f2 00 00 00 00 00 00 00 00
  0x100035804020: 00 00 00 00 00 00 01 f3 f3 f3 f3 f3 00 00 00 00
  0x100035804030: 00 00 00 00 00 00 00 00 ca ca ca ca 00 00 00 05
  0x100035804040: cb cb cb cb 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
==170204==ABORTING

    this error occurs in the do while loop in c1_encode() 

      353  static int c1_encode()
  ...
  388      do {
  ...
  1020     } while (sp < length);

    the check of sp < length in line 1020 is not enough because there are lot of source[sp + i] (and source[sp + 1|2]) accesses which will overflow if sp + i >= length

    aztec.c - aztec_text_process()

    ./zint -b92 -i aztec_text_process-leak-b92
Error 502: Input too long or too many extended ASCII characters

=================================================================
==170410==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 2252 byte(s) in 1 object(s) allocated from:
    #0 0x7f4ba02bfb3a in __interceptor_malloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cc:144
    #1 0x5588315999be in aztec_text_process /zint-2.7.1/backend/aztec.c:140
    #2 0x5588315999be in aztec /zint-2.7.1/backend/aztec.c:1007
    #3 0x558831486a79 in reduced_charset /zint-2.7.1/backend/library.c:859
    #4 0x558831486a79 in extended_or_reduced_charset /zint-2.7.1/backend/library.c:661
    #5 0x55883148c9b5 in ZBarcode_Encode /zint-2.7.1/backend/library.c:1212
    #6 0x558831490d45 in ZBarcode_Encode_File /zint-2.7.1/backend/library.c:1478

Direct leak of 2252 byte(s) in 1 object(s) allocated from:
    #0 0x7f4ba02bfb3a in __interceptor_malloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cc:144
    #1 0x5588315999d0 in aztec_text_process /zint-2.7.1/backend/aztec.c:141
    #2 0x5588315999d0 in aztec /zint-2.7.1/backend/aztec.c:1007
    #3 0x558831486a79 in reduced_charset /zint-2.7.1/backend/library.c:859
    #4 0x558831486a79 in extended_or_reduced_charset /zint-2.7.1/backend/library.c:661
    #5 0x55883148c9b5 in ZBarcode_Encode /zint-2.7.1/backend/library.c:1212
    #6 0x558831490d45 in ZBarcode_Encode_File /zint-2.7.1/backend/library.c:1478

Direct leak of 2252 byte(s) in 1 object(s) allocated from:
    #0 0x7f4ba02bfb3a in __interceptor_malloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cc:144
    #1 0x5588315999ac in aztec_text_process /zint-2.7.1/backend/aztec.c:139
    #2 0x5588315999ac in aztec /zint-2.7.1/backend/aztec.c:1007
    #3 0x558831486a79 in reduced_charset /zint-2.7.1/backend/library.c:859
    #4 0x558831486a79 in extended_or_reduced_charset /zint-2.7.1/backend/library.c:661
    #5 0x55883148c9b5 in ZBarcode_Encode /zint-2.7.1/backend/library.c:1212
    #6 0x558831490d45 in ZBarcode_Encode_File /zint-2.7.1/backend/library.c:1478

SUMMARY: AddressSanitizer: 6756 byte(s) leaked in 3 allocation(s).

    in aztec.c the memory allocated at lines 139-141

         139     encode_mode=(char*)malloc(src_len + 1);
     140     reduced_source=(unsigned char*)malloc(src_len + 1);
     141     reduced_encode_mode=(char*)malloc(src_len + 1);

    is not freed if you return at line 724 this should be easy to fix, i think you can free all three buffers before line 724

         723                 if (count > 2079) {
     724                     return ZINT_ERROR_TOO_LONG;
     725                 }

    library.c - ZBarcode_Encode_File()

    ./zint -i .
Is a directory

=================================================================
==170571==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 82 byte(s) in 1 object(s) allocated from:
    #0 0x7efebabc7b3a in __interceptor_malloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cc:144
    #1 0x5639f9177c22 in ZBarcode_Encode_File /zint-2.7.1/backend/library.c:1457

SUMMARY: AddressSanitizer: 82 byte(s) leaked in 1 allocation(s).

    here its the same again the buffer allocated at line 1454 is not freed if you return at line 1469

        1454     buffer = (unsigned char *) malloc(fileLen * sizeof (unsigned char));
    1465     do {
    1466         n = fread(buffer + nRead, 1, fileLen - nRead, file);
    1467         if (ferror(file)) {
    1468             strcpy(symbol->errtxt, strerror(errno));
    1469             return ZINT_ERROR_INVALID_DATA;
    1470         }
    1471         nRead += n;
    1472     } while (!feof(file) && (0 < n) && (nRead < fileLen));

    i think the same can happen at line 1472

    dotcode.c

    ./zint -b115 -i make_dotstream-b115

/zint-2.7.1/backend/dotcode.c:1096:32: runtime error: index 233 out of bounds for type 'short unsigned int [113]'
/zint-2.7.1/backend/dotcode.c:1096:32: runtime error: load of address 0x55d06c9f3192 with insufficient space for an object of type 'const short unsigned int'
0x55d06c9f3192: note: pointer points here
 67 2f  7a 69 6e 74 2d 72 65 70  6f 72 74 2f 7a 69 6e 74  2d 32 2e 37 2e 31 2f 62  61 63 6b 65 6e 64

    1086 static size_t make_dotstream(unsigned char masked_array[], int array_length, char dot_stream[]) {
1087     int i;
1088
1089     dot_stream[0] = '\0';
1090
1091     /* Mask value is encoded as two dots */
1092     bin_append(masked_array[0], 2, dot_stream);
1093
1094     /* The rest of the data uses 9-bit dot patterns from Annex C */
1095     for (i = 1; i < array_length; i++) {
1096         bin_append(dot_patterns[masked_array[i]], 9, dot_stream);
1097     }
1098
1099     return strlen(dot_stream);
1100 }

    in line 1096 if masked_array[i] is >= 113 memory is read outside of dot_patterns[113]

    1212 static void apply_mask(int mask, int data_length, unsigned char *masked_codeword_array, unsigned char *codeword_array, int ecc_length, char *dot_stream) {
1213     int weight = 0;
1214     int j;
1215
1216     switch (mask) {
1217         case 0:
1218             masked_codeword_array[0] = 0;
1219             for (j = 0; j < data_length; j++) {
1220                 masked_codeword_array[j + 1] = codeword_array[j];

    1269 INTERNAL int dotcode(struct zint_symbol *symbol, const unsigned char source[], int length)
...
1298     data_length = dotcode_encode_message(symbol, source, length, codeword_array, &binary_finish);
...
1423         apply_mask(i, data_length, masked_codeword_array, codeword_array, ecc_length, dot_stream);
1424
1425         dot_stream_length = make_dotstream(masked_codeword_array, (data_length + ecc_length + 1), dot_stream);

    codeword_array is generated by dotcode_encode_message() at line 1298 in dotcode()

    masked_codeword_array is generated by apply_mask() at line 1423 in dotcode()

    If the codeword_array should not contain values >= 113 the error is in dotcode_encode_message() (poc creates codeword_array[395] == 233)

    If the codeword_array can contain values >= 113 the error is in apply_mask() at 1220 => asked_codeword_array[j + 1] = codeword_array[j] % 113;

    pdf417.c - pdf417() / micro_pdf417()

    ./zint -b55 -i pdf417-micro_pdf417-b55-b84

/zint-2.7.1/backend/pdf417.c:572:17: runtime error: index 1000 out of bounds for type 'int [1000]'
/zint-2.7.1/backend/pdf417.c:572:30: runtime error: store to address 0x55b511796d60 with insufficient space for an object of type 'int'
0x55b511796d60: note: pointer points here
 85 03 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00
              ^
=================================================================
==171185==ERROR: AddressSanitizer: global-buffer-overflow on address 0x55b511796d60 at pc 0x55b5113443af bp 0x7fff835b30b0 sp 0x7fff835b30a0
WRITE of size 4 at 0x55b511796d60 thread T0
    #0 0x55b5113443ae in pdf417 /zint-2.7.1/backend/pdf417.c:572
    #1 0x55b511344a78 in pdf417enc /zint-2.7.1/backend/pdf417.c:858
    #2 0x55b5112893ae in reduced_charset /zint-2.7.1/backend/library.c:853
    #3 0x55b5112893ae in extended_or_reduced_charset /zint-2.7.1/backend/library.c:661
    #4 0x55b51128f9b5 in ZBarcode_Encode /zint-2.7.1/backend/library.c:1212
    #5 0x55b511293d45 in ZBarcode_Encode_File /zint-2.7.1/backend/library.c:1478
    #6 0x55b511283127 in main /zint-2.7.1/frontend/main.c:733
    #7 0x7f1f578ad022 in __libc_start_main (/usr/lib/libc.so.6+0x27022)
    #8 0x55b51128598d in _start (/zint-2.7.1/build-asan/frontend/zint+0x29398d)

0x55b511796d60 is located 32 bytes to the left of global variable 'maxi_codeword' defined in '/zint-2.7.1/backend/maxicode.c:41:12' (0x55b511796d80) of size 576
0x55b511796d60 is located 0 bytes to the right of global variable 'liste' defined in '/zint-2.7.1/backend/pdf417.c:85:12' (0x55b511794e20) of size 8000
SUMMARY: AddressSanitizer: global-buffer-overflow /zint-2.7.1/backend/pdf417.c:572 in pdf417
Shadow bytes around the buggy address:
  0x0ab7222ead50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ab7222ead60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ab7222ead70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ab7222ead80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ab7222ead90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0ab7222eada0: 00 00 00 00 00 00 00 00 00 00 00 00[f9]f9 f9 f9
  0x0ab7222eadb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ab7222eadc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ab7222eadd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ab7222eade0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ab7222eadf0: 00 00 00 00 00 00 00 00 f9 f9 f9 f9 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
==171185==ABORTING

    this bug happens with ./zint -b55 (pdf417) and ./zint -b84 (micro_pdf417), maybe the root of this bug is in pdf417_enc(). I tried to understand the problem, but there happens a lot and I didn't get it, sorry.

    there is another bug in pdf417.c maybe this is related

    ./zint -b55 -i byteprocess-b55-b84

=================================================================
==176499==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffce769d850 at pc 0x5556de91941c bp 0x7ffce769a320 sp 0x7ffce769a310
WRITE of size 4 at 0x7ffce769d850 thread T0
    #0 0x5556de91941b in byteprocess /zint-2.7.1/backend/pdf417.c:425
    #1 0x5556de91a475 in pdf417 /zint-2.7.1/backend/pdf417.c:645
    #2 0x5556de91fa78 in pdf417enc /zint-2.7.1/backend/pdf417.c:858
    #3 0x5556de8643ae in reduced_charset /zint-2.7.1/backend/library.c:853
    #4 0x5556de8643ae in extended_or_reduced_charset /zint-2.7.1/backend/library.c:661
    #5 0x5556de86a9b5 in ZBarcode_Encode /zint-2.7.1/backend/library.c:1212
    #6 0x5556de86ed45 in ZBarcode_Encode_File /zint-2.7.1/backend/library.c:1478
    #7 0x5556de85e127 in main /zint-2.7.1/frontend/main.c:733
    #8 0x7f3882f3e022 in __libc_start_main (/usr/lib/libc.so.6+0x27022)
    #9 0x5556de86098d in _start (/zint-2.7.1/build-asan/frontend/zint+0x29398d)

Address 0x7ffce769d850 is located in stack of thread T0 at offset 13296 in frame
    #0 0x5556de9194ff in pdf417 /zint-2.7.1/backend/pdf417.c:554

  This frame has 6 object(s):
    [48, 52) 'indexliste' (line 555)
    [64, 68) 'mclength' (line 556)
    [80, 220) 'dummy' (line 556)
    [288, 2368) 'mccorrection' (line 555)
    [2496, 13296) 'chainemc' (line 556) <== Memory access at offset 13296 overflows this variable
    [13552, 14132) 'pattern' (line 557)
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 /zint-2.7.1/backend/pdf417.c:425 in byteprocess
Shadow bytes around the buggy address:
  0x10001cecbab0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10001cecbac0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10001cecbad0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10001cecbae0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10001cecbaf0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x10001cecbb00: 00 00 00 00 00 00 00 00 00 00[f2]f2 f2 f2 f2 f2
  0x10001cecbb10: f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2
  0x10001cecbb20: f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 00 00 00 00 00 00
  0x10001cecbb30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10001cecbb40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10001cecbb50: 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
==176499==ABORTING

    aztec.c -aztec_text_process()

    /zint -b92 -i bin_append-b92

=================================================================
==176379==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffd1d40a540 at pc 0x55d81c94f5da bp 0x7ffd1d4054a0 sp 0x7ffd1d405490
WRITE of size 1 at 0x7ffd1d40a540 thread T0
    #0 0x55d81c94f5d9 in bin_append_posn /zint-2.7.1/backend/common.c:70
    #1 0x55d81c94f6e6 in bin_append /zint-2.7.1/backend/common.c:57
    #2 0x55d81c8a0af1 in aztec_text_process /zint-2.7.1/backend/aztec.c:799
    #3 0x55d81c8a0af1 in aztec /zint-2.7.1/backend/aztec.c:1007
    #4 0x55d81c78aa79 in reduced_charset /zint-2.7.1/backend/library.c:859
    #5 0x55d81c78aa79 in extended_or_reduced_charset /zint-2.7.1/backend/library.c:661
    #6 0x55d81c7909b5 in ZBarcode_Encode /zint-2.7.1/backend/library.c:1212
    #7 0x55d81c794d45 in ZBarcode_Encode_File /zint-2.7.1/backend/library.c:1478
    #8 0x55d81c784127 in main /zint-2.7.1/frontend/main.c:733
    #9 0x7f829b74c022 in __libc_start_main (/usr/lib/libc.so.6+0x27022)
    #10 0x55d81c78698d in _start (/zint-2.7.1/build-asan/frontend/zint+0x29398d)

Address 0x7ffd1d40a540 is located in stack of thread T0 at offset 20176 in frame
    #0 0x55d81c89be1f in aztec /zint-2.7.1/backend/aztec.c:973

  This frame has 6 object(s):
    [48, 52) 'desc_data' (line 977)
    [64, 70) 'desc_ecc' (line 977)
    [96, 138) 'descriptor' (line 975)
    [176, 20176) 'binary_string' (line 975) <== Memory access at offset 20176 overflows this variable
    [20432, 40432) 'adjusted_string' (line 976)
    [40688, 60733) 'bit_pattern' (line 975)
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 /zint-2.7.1/backend/common.c:70 in bin_append_posn
Shadow bytes around the buggy address:
  0x100023a79450: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x100023a79460: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x100023a79470: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x100023a79480: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x100023a79490: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x100023a794a0: 00 00 00 00 00 00 00 00[f2]f2 f2 f2 f2 f2 f2 f2
  0x100023a794b0: f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2
  0x100023a794c0: f2 f2 f2 f2 f2 f2 f2 f2 00 00 00 00 00 00 00 00
  0x100023a794d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x100023a794e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x100023a794f0: 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
==176379==ABORTING

    If I understand it right length in bin_append() and bin_append_posn() is the length of the data you append and not the max length of the buffer
    and the bug is in aztec_text_process() where you should guarantee that a call of bin_append() can't overflow your binary_string

    I hope this helps you,
    Nico

     
    poc.tar.gz

  • Robin Stuart

    Robin Stuart - 2020-03-29

    Thank you for finding the time to test Zint so thoroughly. After much effort (mostly from Git Lost) I think all of these bugs have now been sorted out. If Chris or Nico could could please confirm this then I think it would be a relief to close this ticket!

     

  • Nico Gunkel

    Nico Gunkel - 2020-03-31

    I tested the gitlost-zint 22354a81f12af9f9b68fae4fb48bac8bee93d698 version and run all my test cases and found one more in the dotcode.c. I didn't reported it previously because I thought it was a duplicate of the other dotcode bug. Sorry for that.

    This bug is strange I can trigger it only if I compile zint with gcc (version 9.3.0) and asan, with clang and asan I can't reproduce it. The inputs are in the attachment. All inputs trigger the same bug at different locations. Its always an access to codeword_array[array_length] with a too large array_length.

    ./zint -b115 -i dotcode_777-b115

==831668==ERROR: AddressSanitizer: dynamic-stack-buffer-overflow on address 0x7ffc682f73a6 at pc 0x7f10c5ab306f bp 0x7ffc682f7230 sp 0x7ffc682f7220
WRITE of size 1 at 0x7ffc682f73a6 thread T0
    #0 0x7f10c5ab306e in dotcode_encode_message /gitlost-zint/backend/dotcode.c:777
    #1 0x7f10c5abaaee in dotcode /gitlost-zint/backend/dotcode.c:1317
    #2 0x7f10c5908e6d in reduced_charset /gitlost-zint/backend/library.c:860
    #3 0x7f10c5907734 in extended_or_reduced_charset /gitlost-zint/backend/library.c:660
    #4 0x7f10c590e4d3 in ZBarcode_Encode /gitlost-zint/backend/library.c:1211
    #5 0x7f10c5910e92 in ZBarcode_Encode_File /gitlost-zint/backend/library.c:1491
    #6 0x55d7863cf023 in main /gitlost-zint/frontend/main.c:733
    #7 0x7f10c48f6022 in __libc_start_main (/usr/lib/libc.so.6+0x27022)
    #8 0x55d7863c536d in _start (/gitlost-zint/build/frontend/zint+0x1136d)

Address 0x7ffc682f73a6 is located in stack of thread T0 at offset 230 in frame
    #0 0x7f10c5aadb76 in dotcode_encode_message /home/gunkelni/projects/gitlost-zint/backend/dotcode.c:455

  This frame has 1 object(s):
    [32, 56) 'lawrencium' (line 461) <== Memory access at offset 230 overflows this variable
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: dynamic-stack-buffer-overflow /home/gunkelni/projects/fuzzing/barcode-fuzzing/zint/gitlost-zint/backend/dotcode.c:777 in dotcode_encode_message
Shadow bytes around the buggy address:
  0x10000d056e20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10000d056e30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10000d056e40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10000d056e50: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 00 00 f3
  0x10000d056e60: f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00
=>0x10000d056e70: ca ca ca ca[06]cb cb cb cb cb cb cb 00 00 00 00
  0x10000d056e80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10000d056e90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10000d056ea0: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1
  0x10000d056eb0: f1 f1 04 f2 00 00 00 00 f3 f3 f3 f3 00 00 00 00
  0x10000d056ec0: 00 00 00 00 00 00 00 00 ca ca ca ca 03 cb cb cb
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
==831668==ABORTING

    All other bugs are fixed in my opinion, thanks for the replay and your work done here.

     
    dotcode.tar.gz

  • Git Lost

    Git Lost - 2020-03-31

    Thanks very much Nico, [f51499] should address the DOTCODE codearray overflow.

     

    Related

    Commit: [f51499]


    Last edit: Git Lost 2020-03-31

  • Nico Gunkel

    Nico Gunkel - 2020-04-01

    Yes fr1499 fixed it, I think this ticket can be closed

     

  • Harald Oehlmann

    Harald Oehlmann - 2020-04-01
    • status: open --> closed
     

  • Harald Oehlmann

    Harald Oehlmann - 2020-04-01

    Git-Lost has confirmed that all found bugs are fixed.
    Cudos to all bug-hunters,
    Harald

     

  • Stf Ortm

    Stf Ortm - 2024-02-12

    Hi Zint Team,

    Snyk CLI indicates after processing a vulnerability check that "CVE-2020-9385" is still present. Can you give a short information that "CVE-2020-9385" is fixed in ZINT 2.10.9? Or do we have to update to 2.13.x?
    Thank you very much!

    Best regards
    Stefan

    Links

     

    Last edit: Stf Ortm 2024-02-12
    Thumbnail
    cmd.png
    Thumbnail
    snyk.png

    • Git Lost

      Git Lost - 2024-02-13

      Hi Stefan, the bugs mentioned in this ticket should have been fixed with zint 2.8.0. Test cases were added for all the issues mentioned.

      The attached PNGs don't show what the input data is that triggers the NULL pointer dereference, so it's hard to tell if the same issues are being tested.

      Could you supply the input data that you're testing with? Thanks, Martin

      P.S. Please note regardless that only the latest version of zint, 2.13.0, is supported, so it would be best if you would run your tests against it.

       

  • Stf Ortm

    Stf Ortm - 2024-02-14

    Hi Git Lost,
    Thank you for the quick response.

    I downloaded ZINT 2.13 from commit f312cdf6304df567b5c68de0338d1869c0869e6f.

    The file backend\zintconfig.h contains the following version information:
    ZINT_VERSION_MAJOR 2
    ZINT_VERSION_MINOR 13
    ZINT_VERSION_RELEASE 0
    ZINT_VERSION_BUILD 9

    After running the latest version of Snyk, the vulnerability was indicated again.

    This can be a false positive, because Snyk checks the fingerprints of the files again a database.
    Maybe the Snyk scanner fails because the fingerprints of the 2.10.x are identical to 2.13.x files because these files had no errors in the past and used identical in the latest version.

    Unfortunately, I cannot recognize which files are problematic, therefore I attach the commands and JSON output.

    It would be nice if you could have a look inside the files.
    Do you also use a vulnerability check tool or could you give a hint?

    Thank you!
    Stefan

     

    Last edit: Stf Ortm 2024-02-14
    Thumbnail
    commands.png
    links-and-commands.txt
    Thumbnail
    project-info.png
    vulnerabilities.json

    • Git Lost

      Git Lost - 2024-02-15

      Hi Stefan, thanks for attachments but I don't see any information there that could help me determine what the input data is that leads to the vulnerability.

      I don't know anything about Snyk, which it appears I need to sign up for to use, which I do not wish to do. Even if I did it would appear from the "commands.png" attachment that all it would do is dump the overview at https://security.snyk.io/vuln/SNYK-UNMANAGED-ZINT-2380686 in JSON format ("vulnerabilities.json"), which gives no details about how to reproduce the issue.

      You mention files, but I don't know what they are. Are they data files that Snyk references in its database? Can they be downloaded or accessed in any way?

      Re vulnerability check tool, no, zint does not use such a tool, whose existence is news to me.

      Zint has a large test suite, the bulk of which is located in "test_XXX.c" files in "backend/tests" in the project directory. For instance the first issue on this ticket concerning EAN and the input "55++15" is tested for at https://sourceforge.net/p/zint/code/ci/master/tree/backend/tests/test_upcean.c#l991

      Regards, Martin

       

  • Stf Ortm

    Stf Ortm - 2024-02-16

    Hi Martin,
    I did a static analysis yesterday to find references to vulnerable .c/.h files. The result (including the commandlines and the list of scanned files) is attached. There are some suggestions included but there is no hint of an open or existing CVE in 2.13.9.
    This CVE is therefore solved for me and from my point of view ticket 181 should remain closed.
    Thank you for your patience and time.

    Best regards,
    Stefan

     
    static-code-analysis.txt

    • Git Lost

      Git Lost - 2024-02-27

      Hi Stefan, thanks for the analysis. The only ones that seem fully relevant to me are the 2 "Dereference of a NULL Pointer" issues which should be fixed by commit [f0d890].

      The "Improper Null Termination" ones seem on looking at each instance to be false positives, and the "Potential buffer overflow from usage of unsafe function" ones result from zint using strcpy(), sprintf(), etc which I've no plans to replace, although this might change in the future (OpenBSD for one changed their linker to issue an unsuppressible warning when these are used which is irritating).

      Thanks, Martin

       

      Related

      Commit: [f0d890]

Log in to post a comment.

MongoDB Logo MongoDB