Re: [PATCH] t4062: stop using repetition in regex

From: René Scharfe <l.s.r@web.de>
Date: Aug 8, 2017, 15:18 UTC
Message-ID: <1e7ed028-77fe-195a-4acf-6c80d1704463@web.de>
In-Reply-To: <alpine.DEB.2.21.1.1708081648130.11175@virtualbox>

Am 08.08.2017 um 16:49 schrieb Johannes Schindelin:

Show 15 quoted lines

> Hi René,
> 
> On Tue, 8 Aug 2017, René Scharfe wrote:
> 
>> OpenBSD's regex library has a repetition limit (RE_DUP_MAX) of 255.
>> That's the minimum acceptable value according to POSIX.  In t4062 we use
>> 4096 repetitions in the test "-G matches", though, causing it to fail.
>>
>> Do the same as the test "-S --pickaxe-regex" in the same file and search
>> for a single zero instead.  That still suffices to trigger the buffer
>> overrun in older versions (checked with b7d36ffca02^ and --valgrind on
>> Linux), simplifies the test a bit, and avoids exceeding OpenBSD's limit.
> 
> I am afraid not. The 4096 is precisely the page size required to trigger
> the bug on Windows against which this regression test tries to safeguard.

Checked with b7d36ffca02^ on MinGW now as well and found that it segfaults with the proposed change ten out of ten times.

You get different results? How is that possible? The search string is NUL-terminated in each case, while the point of the test is that the file contents isn't, right?

> Maybe simply disable the test on OpenBSD instead? Or guard the {4096}
> behind the MINGW prereq.

It's easy to build a long search string with two repetitions or by using a longer string as the base, if necessary. But first we need to find out why regexec() doesn't overflow in your case. My build uses the version from compat/. Why would it stop before reaching a NUL? That sounds like a different and serious bug.

Thanks, René