Re: buffer overflow in regcomp and a way to find more of those

[Konstantin Serebryany <konstantin.s.serebryany@gmail.com>]

After your fix the fuzzer did not find anything else so far, but it
suffers from slow performance on some cases.
Not sure if this qualifies for a bug, but the following example takes
~2 seconds to run (runs instantly with glibc):
int main() {
  regex_t preg;
  const char *s = ".****\\Z$<\\0)_";
  regmatch_t pmatch[2];
  if (0 == regcomp(&preg, s, 0)) {
    regexec(&preg, s, 0, pmatch, 0);
    regfree(&preg);
  }
  return 0;
}


On Fri, Mar 20, 2015 at 6:05 PM, Konstantin Serebryany
<konstantin.s.serebryany@gmail.com> wrote:
> On Fri, Mar 20, 2015 at 6:00 PM, Rich Felker <dalias@libc.org> wrote:
>> On Fri, Mar 20, 2015 at 05:54:49PM -0700, Konstantin Serebryany wrote:
>>> >> > > the question is how hard it is to do (1) ?
>>> >> > >
>>> >> > > i assume asan is non-trivial to set up for that (or is it
>>> >> > > enough to replace malloc calls? and some startup logic?)
>>> >> >
>>> >> > asan replaces malloc and a few more libc functions.
>>> >> > It works with various different libcs, so there is a good chance that
>>> >> > it will work here with no or minimal changes.
>>> >>
>>> >> ok i'll try it
>>> >
>>> > I would guess it works with no change for static linking, but some
>>> > changes might be needed for dynamic linking. I'm perfectly happy with
>>> > all the fuzzing being done with static linking anyway; I don't think
>>> > dynamic linking would have significant additional code paths whose
>>> > coverage need checking.
>>>
>>> sadly, asan does not support fully static linking.
>>
>> Is this just an oversight or something fundamental that's hard to fix?
>
> Quite fundamental.
> asan needs to be able to intercept certain libc functions and on all
> platforms (linux, android, OSX, Windows, etc) it works only when libc
> itself is dynamically linked.
>
> (Theoretically, it's possible to fix, but it'll be  too much work :( )
>
>> The sort of things it wants to do are much less likely to work with
>> dynamic linking. Dynamic-linked musl requires all internal symbol
>> references to be resolved at ld-time and does not support interposing
>> in front of them.
>>
>> Rich