[pcre-dev] [Bug 2320] Buffer Overflow in PCRE2 jit

Top Page
Delete this message
Author: admin
Date:  
To: pcre-dev
Old-Topics: [pcre-dev] [Bug 2320] New: Buffer Overflow in PCRE2 jit
Subject: [pcre-dev] [Bug 2320] Buffer Overflow in PCRE2 jit
https://bugs.exim.org/show_bug.cgi?id=2320

YangCONG <yangcong11@???> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Hardware|x86                         |x86-64
            Version|10.31 (PCRE2)               |8.42


--- Comment #7 from YangCONG <yangcong11@???> ---
(In reply to Zoltan Herczeg from comment #6)
> Please check the commit:
>
> https://lists.exim.org/lurker/message/20180918.101914.6629b8f3.en.html
>
> A simple pattern is enough to reproduce the issue:
>
> /\X{2}/
>     \r\n\n


Thank you for your reply.

But I really don't know how to use the case to reproduce buffer overflow!

Can you tell me the specific commands for configuration, make, and execution in
the PCRE 8.42?

I added a command to the file pcre_jit_test.c

{ PCRE_NEWLINE_ANY, 0, "\\R{2}", "\r\n\n" },
{ PCRE_NEWLINE_ANY, 0, "\\X{2}", "\r\n\n" },

I have installed libtools and valgrind.

- Build command
$ ./configure --disable-shared --enable-pcre16 --enable-pcre32 --enable-jit
--enable-unicode-properties&& make clean all

$ make && make test

Pattern: ▒%B%2 :

8 bit: Cannot compile pattern "▒%B%2": invalid UTF-8 string

8 and 16 bit: Return value differs(J8:-1000,J16:1): [3] '▒%B%2' @ '▒%▒%2'

$ valgrind --tool=memcheck --leak-check=full ./pcre_jit_test

   ==30244== Memcheck, a memory error detector
   ==30244== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
   ==30244== Using Valgrind-3.12.0 and LibVEX; rerun with -h for copyright info
   ==30244== Command: ./pcre_jit_test
   ==30244==
  Running JIT regression tests
    target CPU of SLJIT compiler: x86 64bit (little endian + unaligned)
     in  8 bit mode with UTF-8  enabled and ucp enabled:
     in 16 bit mode with UTF-16 enabled and ucp enabled:
     in 32 bit mode with UTF-32 enabled and ucp enabled:


Pattern: \R{2} :
.
Pattern: \X{2} :
.
Pattern: ▒%B%2 :

8 bit: Cannot compile pattern "▒%B%2": invalid UTF-8 string

8 and 16 bit: Return value differs(J8:-1000,J16:1): [3] '▒%B%2' @ '▒%▒%2'

  ==30244== Invalid read of size 1
  ==30244==    at 0x52AACC0: vfprintf (vfprintf.c:1632)
  ==30244==    by 0x53729EE: __printf_chk (printf_chk.c:35)
  ==30244==    by 0x401698: printf (stdio2.h:104)
  ==30244==    by 0x401698: regression_tests (pcre_jit_test.c:543)
  ==30244==    by 0x400F47: main (pcre_jit_test.c:114)
  ==30244==  Address 0xffffffff000000a2 is not stack'd, malloc'd or (recently) 
  free'd
  ==30244==
  ==30244==
  ==30244== Process terminating with default action of signal 11 (SIGSEGV)
  ==30244==  Access not within mapped region at address 0xFFFFFFFF000000A2
  ==30244==    at 0x52AACC0: vfprintf (vfprintf.c:1632)
  ==30244==    by 0x53729EE: __printf_chk (printf_chk.c:35)
  ==30244==    by 0x401698: printf (stdio2.h:104)
  ==30244==    by 0x401698: regression_tests (pcre_jit_test.c:543)
  ==30244==    by 0x400F47: main (pcre_jit_test.c:114)
  ==30244==  If you believe this happened as a result of a stack
  ==30244==  overflow in your program's main thread (unlikely but
  ==30244==  possible), you can try to increase the size of the
  ==30244==  main thread stack using the --main-stacksize= flag.
  ==30244==  The main thread stack size used in this run was 8388608.
  Pattern: ==30244==
  ==30244== HEAP SUMMARY:
  ==30244==     in use at exit: 1,152 bytes in 3 blocks
  ==30244==   total heap usage: 75 allocs, 72 frees, 71,587 bytes allocated
  ==30244==
  ==30244== LEAK SUMMARY:
  ==30244==    definitely lost: 0 bytes in 0 blocks
  ==30244==    indirectly lost: 0 bytes in 0 blocks
  ==30244==      possibly lost: 0 bytes in 0 blocks
  ==30244==    still reachable: 1,152 bytes in 3 blocks
  ==30244==         suppressed: 0 bytes in 0 blocks
  ==30244== Reachable blocks (those to which a pointer was found) are not
shown.
  ==30244== To see them, rerun with: --leak-check=full --show-leak-kinds=all
  ==30244==
  ==30244== For counts of detected and suppressed errors, rerun with: -v
  ==30244== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
  Segmentation fault (core dumped)



Then I add the patch

&& type != OP_ANYNL && type != OP_EXTUNI

and re-execute command.

But the result is the same. Is a new bug or something go wrong?

Is that the test case { PCRE_NEWLINE_ANY, 0, "\\X{2}", "\r\n\n" } is wrong?


Another question is how to the run the command with jit support like this
-$ ./pcre2test -32 -jit ./crash.txt
with PCRE 8.4x series.




(In reply to Zoltan Herczeg from comment #6)
> Please check the commit:
>
> https://lists.exim.org/lurker/message/20180918.101914.6629b8f3.en.html
>
> A simple pattern is enough to reproduce the issue:
>
> /\X{2}/
>     \r\n\n


--
You are receiving this mail because:
You are on the CC list for the bug.