GNU bug report logs - #51710
[PATCH] pcre: avoid overflow in PCRE JIT stack resizing

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Carlo Marcelo Arenas Belón <carenas <at> gmail.com>
Subject: bug#51710: closed (Re: bug#51710: [PATCH] pcre: avoid overflow in
 PCRE JIT stack resizing)
Date: Tue, 09 Nov 2021 18:29:01 +0000

[Message part 1 (text/plain, inline)]

Your bug report

#51710: [PATCH] pcre: avoid overflow in PCRE JIT stack resizing

which was filed against the grep package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to 51710 <at> debbugs.gnu.org.

-- 
51710: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=51710
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Carlo Marcelo Arenas Belón <carenas <at> gmail.com>
Cc: 51710-done <at> debbugs.gnu.org
Subject: Re: bug#51710: [PATCH] pcre: avoid overflow in PCRE JIT stack resizing
Date: Tue, 9 Nov 2021 10:28:07 -0800

[Message part 3 (text/plain, inline)]

Thanks for reporting that. I installed the attached somewhat-simpler patch.

Does PCRE2 have a similar bug? If so, I suppose this should be reflected 
when we merge in the patch for bug#47264.

[0001-grep-work-around-PCRE-bug.patch (text/x-patch, attachment)]

[Message part 5 (message/rfc822, inline)]

From: Carlo Marcelo Arenas Belón <carenas <at> gmail.com>
To: bug-grep <at> gnu.org
Cc: Carlo Marcelo Arenas Belón <carenas <at> gmail.com>
Subject: [PATCH] pcre: avoid overflow in PCRE JIT stack resizing
Date: Tue,  9 Nov 2021 00:33:09 -0800

fbc60d4 (Grow the JIT stack if it becomes exhausted, 2015-02-10), add
support to grep for recovering from a JIT stack exhaustion problem,
by creating and using increasingly larger stacks.

The underlying problem might seem to have been generated by a PCRE bug
that is no longer reproducible, and the code could be simplified to do
a single iteration instead with a theoretical maximum of almost INT_MAX,
but that could be a regression, so instead make sure that the maximum
size requested will always be valid, by avoiding a PCRE internal int
overflow that will then be translated into an UINT_MAX like value by
sljit.

Alternatively, a smaller maximum could be selected as it has been
documented[1] that more than 1MB would be unrealistic.

[1] https://www.pcre.org/original/doc/html/pcrejit.html#SEC8

Signed-off-by: Carlo Marcelo Arenas Belón <carenas <at> gmail.com>
---
 src/pcresearch.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/src/pcresearch.c b/src/pcresearch.c
index 3bdaee9..c4fb09b 100644
--- a/src/pcresearch.c
+++ b/src/pcresearch.c
@@ -77,6 +77,10 @@ jit_exec (struct pcre_comp *pc, char const *subject, int search_bytes,
         {
           int old_size = pc->jit_stack_size;
           int new_size = pc->jit_stack_size = old_size * 2;
+
+          /* PCRE will round up 8K bytes, so avoid overflow in maximum  */
+          if (INT_MAX - new_size < 8192)
+            new_size = INT_MAX - 8192;
           if (pc->jit_stack)
             pcre_jit_stack_free (pc->jit_stack);
           pc->jit_stack = pcre_jit_stack_alloc (old_size, new_size);
-- 
2.34.0.rc1.349.g8f33748433

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.