[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150321002616.GF16260@port70.net>
Date: Sat, 21 Mar 2015 01:26:16 +0100
From: Szabolcs Nagy <nsz@...t70.net>
To: musl@...ts.openwall.com
Cc: Konstantin Serebryany <konstantin.s.serebryany@...il.com>
Subject: Re: buffer overflow in regcomp and a way to find more of those
* Konstantin Serebryany <konstantin.s.serebryany@...il.com> [2015-03-20 17:06:18 -0700]:
> On Fri, Mar 20, 2015 at 4:52 PM, Szabolcs Nagy <nsz@...t70.net> wrote:
> > * 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.
> >>
> >
> > (now with correct To: header)
> >
> >
> > (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.
>
> Correct. Building libc.a is simple:
> CC="clang -fsanitize=address -fsanitize-coverage=3 " ./configure && make -j
> But then I don't know how to properly link libc.a to a test case.
> How do you usually link tests with libc.a on x86_64 linux?
>
we have a musl-gcc script when the compiler is gcc (it uses
a simple spec file to set things up), i don't know what's
the equivalent mechanism in clang world, but i think one
can create a simple script based on the first version of
musl-gcc
http://git.musl-libc.org/cgit/musl/commit/?id=58f430c1e0255c0b28aed1e9bf3d892c18c06631
the test system does not know about toolchain details
the user has to provide whatever compiler wrapper script
is needed to make things work
but i think i wont try to integrate this into our libc-test
right away, libc-test is designed to test a posix libc with
minimal assumptions or external dependencies
(the testing process of musl is not very formal or automated
yet anyway)
> > 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
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.
