On Tue, 6 Sep 2016, Jeff King wrote:
> On Mon, Sep 05, 2016 at 05:44:57PM +0200, Johannes Schindelin wrote:
> > The problem with that: mmap()ed memory is *not* NUL-terminated, yet
> > the pickaxe code calls regexec() on it just the same.
> > This problem has been reported by my colleague Chris Sidi.
> > Please note that this patch series is a hot fix I applied to Git for
> > Windows (the bug does not trigger a segmentation fault for me on
> > Linux, strangely enough, but it is really a problem on Windows).
> This has come up before, and I think somebody mentioned that on Linux,
> you are OK unless the buffer ends right at a page boundary (i.e., the
> buffer size is a multiple of the page size). I don't know if that's true
> or not.
In my tests on Linux, even when the buffer ended right at the page
boundary, the memory after that was still legal to access, and typically
had a NUL *somewhere*.
That's happenstance, of course, and could very well result in false
positives (however unlikely that is).
> > So at least I have a workaround in place. Ideally, though, we would
> > NUL-terminate the buffers only when needed, or somehow call regexec() on
> > ptr/size parameters instead of passing a supposedly NUL-terminated
> > string to it?
> There's some discussion in:
> and the thread below it. The quickest way to fix regexec() would be to
> have everybody use the built-in GNU regex in compat/. People seemed
> somewhat positive on that direction, but we never followed up.
I had a brief look, and it is not pretty. You would have to pay me good
money to dive in and try to implement a regexecn() based on what we have
in compat/regex/. And then people would still complain, I guess, for not
using the native regex support, where available.