[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150320234858.GD16260@port70.net>
Date: Sat, 21 Mar 2015 00:48:58 +0100
From: Szabolcs Nagy <nsz@...t70.net>
To: musl@...ts.openwall.com, Szabolcs Nagy <szabolcs.nagy@....com>
Subject: Re: buffer overflow in regcomp and a way to find more of those
* Szabolcs Nagy <nsz@...t70.net> [2015-03-20 22:28:03 +0100]:
> * Konstantin Serebryany <konstantin.s.serebryany@...il.com> [2015-03-20 13:17:47 -0700]:
> > Following the discussion at the glibc mailing list
> > (https://sourceware.org/ml/libc-alpha/2015-03/msg00662.html)
> > I've tried to fuzz musl regcomp and the first bug popped up quickly.
> > Please let me know if you would be interested in adding the fuzzer
> > (http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Fuzzer/README.txt?view=markup)
> > to the musl testing process.
ok
(1) the clean approach would be to have a way to build an
instrumented libc and a separate set of test cases for
various libc apis that the fuzzer could use.
(2) the other approach is to cut parts of the libc out
(the parsers often don't depend on too much libc internals)
and build them with whatever runtime the fuzzer needs
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?)
at first it is ok if the fuzzer only catches crashing bugs
so if that's easy to do i'd go for that.
for (1) i can write the test cases and adjust the musl build
system, but i dont know how much difficulty should i expect
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
