[pcre-dev] [Bug 1741] New: Invalid memory accesses in get_fi…

Page principale
Supprimer ce message
Auteur: admin
Date:  
À: pcre-dev
Sujet: [pcre-dev] [Bug 1741] New: Invalid memory accesses in get_first_set (pcre_get.c)
https://bugs.exim.org/show_bug.cgi?id=1741

            Bug ID: 1741
           Summary: Invalid memory accesses in get_first_set (pcre_get.c)
           Product: PCRE
           Version: 8.38
          Hardware: x86-64
                OS: Linux
            Status: NEW
          Severity: bug
          Priority: medium
         Component: Code
          Assignee: ph10@???
          Reporter: thomas.lindroth@???
                CC: pcre-dev@???


Fuzzing pcre-1 (8.39-RC1 svn r1617) with afl has turned up some invalid memory
accesses in get_first_set (pcre_get.c)

pattern: /(?<A>)(?J:(?<B>)(?<B>))(?<C>)/
data: \O\CC

valgrind pcretest
==30883== Memcheck, a memory error detector
==30883== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==30883== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==30883== Command: pcretest
==30883==
PCRE version 8.39-RC1 2015-11-23

re> /(?<A>)(?J:(?<B>)(?<B>))(?<C>)/
data> \O\CC

Matched, but too many substrings
==30883== Invalid read of size 4
==30883==    at 0x4E4A61E: get_first_set.part.0 (pcre_get.c:298)
==30883==    by 0x4E4A720: get_first_set (pcre_get.c:282)
==30883==    by 0x4E4A720: pcre_copy_named_substring (pcre_get.c:405)
==30883==    by 0x40472A: main (pcretest.c:5356)
==30883==  Address 0x20 is not stack'd, malloc'd or (recently) free'd
==30883== 
==30883== 
==30883== Process terminating with default action of signal 11 (SIGSEGV)
==30883==  Access not within mapped region at address 0x20
==30883==    at 0x4E4A61E: get_first_set.part.0 (pcre_get.c:298)
==30883==    by 0x4E4A720: get_first_set (pcre_get.c:282)
==30883==    by 0x4E4A720: pcre_copy_named_substring (pcre_get.c:405)
==30883==    by 0x40472A: main (pcretest.c:5356)
==30883==  If you believe this happened as a result of a stack
==30883==  overflow in your program's main thread (unlikely but
==30883==  possible), you can try to increase the size of the
==30883==  main thread stack using the --main-stacksize= flag.
==30883==  The main thread stack size used in this run was 8388608.
==30883== 
==30883== HEAP SUMMARY:
==30883==     in use at exit: 133,073 bytes in 5 blocks
==30883==   total heap usage: 5 allocs, 0 frees, 133,073 bytes allocated
==30883== 
==30883== LEAK SUMMARY:
==30883==    definitely lost: 0 bytes in 0 blocks
==30883==    indirectly lost: 0 bytes in 0 blocks
==30883==      possibly lost: 0 bytes in 0 blocks
==30883==    still reachable: 133,073 bytes in 5 blocks
==30883==         suppressed: 0 bytes in 0 blocks
==30883== Rerun with --leak-check=full to see details of leaked memory
==30883== 
==30883== For counts of detected and suppressed errors, rerun with: -v
==30883== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
Segmentation fault


pcretest -C
PCRE version 8.39-RC1 2015-11-23
Compiled with
8-bit support
No UTF-8 support
No Unicode properties support
No just-in-time compiler support
Newline sequence is LF
\R matches all Unicode newlines
Internal link size = 2
POSIX malloc threshold = 10
Parentheses nest limit = 250
Default match limit = 10000000
Default recursion depth limit = 10000000
Match recursion uses stack

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