Heap-Buffer-Overflow in pcre2(src/pcre2_match.c:6996:27 in pcre2_match_8)

[longuu9]

We found a heap-buffer-overflow in pcre2-10.43-DEV(src/pcre2_match.c:6996:27 in pcre2_match_8),which can also be reproduced on pcre2-10.42.

Command Input

pcre2test -d poc_file /dev/null

poc_file are attached.

Sanitizer Dump

==746652==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x629000004201 at pc 0x000000630891 bp 0x7ffc4c304f90 sp 0x7ffc4c304f88
READ of size 1 at 0x629000004201 thread T0
    #0 0x630890 in pcre2_match_8 /root/target/Invariants/pcre2/src/pcre2_match.c:6996:27
    #1 0x7f6b71 in pcre2_regexec /root/target/Invariants/pcre2/src/pcre2posix.c:388:6
    #2 0x4e3c9a in process_data /root/target/Invariants/pcre2/src/pcre2test.c:7295:8
    #3 0x4cef20 in main /root/target/Invariants/pcre2/src/pcre2test.c:9470:12
    #4 0x7f01d38de082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/../csu/libc-start.c:308:16
    #5 0x41c35d in _start (/root/target/Invariants/pcre2/pcre2test+0x41c35d)

0x629000004201 is located 1 bytes to the right of 16384-byte region [0x629000000200,0x629000004200)
allocated by thread T0 here:
    #0 0x4978d9 in realloc /root/test/fuzzing_python/llvm-project-llvmorg-12.0.0/compiler-rt/lib/asan/asan_malloc_linux.cpp:164:3
    #1 0x4de0d0 in process_data /root/target/Invariants/pcre2/src/pcre2test.c:6867:24
    #2 0x4cef20 in main /root/target/Invariants/pcre2/src/pcre2test.c:9470:12
    #3 0x7f01d38de082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/../csu/libc-start.c:308:16

SUMMARY: AddressSanitizer: heap-buffer-overflow /root/target/Invariants/pcre2/src/pcre2_match.c:6996:27 in pcre2_match_8
Shadow bytes around the buggy address:
  0x0c527fff87f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c527fff8800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c527fff8810: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c527fff8820: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c527fff8830: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0c527fff8840:[fa]fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c527fff8850: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c527fff8860: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c527fff8870: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c527fff8880: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c527fff8890: 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
==746652==ABORTING

Environment

• OS: Ubuntu 20.04.1
• clang:12.0.0
• pcre2:pcre2-10.43-DEV

we built pcre2 with AddressSanitizer (ASAN) .

./configure CC=clang CXX=clang++ CFLAGS='-g -O0 -fsanitize=address' CXXFLAGS='-g -O0 -fsanitize=address' --disable-shared

pcre2-10.43-DEV configuration summary:

    Install prefix ..................... : /usr/local
    C preprocessor ..................... : clang -E
    C compiler ......................... : clang
    Linker ............................. : /usr/bin/ld -m elf_x86_64
    C preprocessor flags ............... : 
    C compiler flags ................... : -g -O0 -fsanitize=address -fvisibility=hidden
    Linker flags ....................... : 
    Extra libraries .................... : 

poc_file.zip

[PhilipHazel]

This is a more subtle non-issue. You are using pcre2test to call the POSIX interface to PCRE2. The failing test is:

/^d(e)$/posix
\=posix_startend=2:4

The second line means you are passing an empty string to be matched, but selecting the start and end offsets as 2 and 4, clearly outside the string. You might think that the offsets can be checked to be within the string, but this isn't possible because this feature was implemented to make it possible for the POSIX interface to match against strings that contain binary zeroes. Hence the actual string length isn't know. (In the native PCRE2 API, the string length can be given explicitly.)