This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Should memchr work with invalid data size?
- From: Carlos O'Donell <carlos at redhat dot com>
- To: "H.J. Lu" <hjl dot tools at gmail dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Thu, 18 May 2017 00:22:10 -0400
- Subject: Re: Should memchr work with invalid data size?
- Authentication-results: sourceware.org; auth=none
- References: <CAMe9rOoZfLVq5_K1Nz16FuH50FBHSvE4J3cFysQBYC_Bxpq9sw@mail.gmail.com>
On 05/17/2017 06:24 PM, H.J. Lu wrote:
> "main memchr" says
>
> The memchr() function scans the initial n bytes of the memory area
> pointed to by s for the first instance of c.
>
> But test-memchr.c has
>
> if (pos < len)
> {
> size_t r = random ();
> if ((r & 31) == 0)
> len = ~(uintptr_t) (p + align) - ((r >> 5) & 31);
> result = (CHAR *) (p + pos + align);
> }
>
> which sets len to some random value, like 18446603336355475958.
> Should memchr work with it?
A caller should expect the implementation may read any memory
location from "(char *)s" to "(char *)s + n - 1".
Therefore the above _might_ work depending on the implementation.
Could you please add lots of comments to do_random_tests() and
explain what it's doing and why?
It might have been a valid white-box test to try use a large value
of size_t randomly for an implementation that scans from the front
to back. You would do this kind of testing when looking for overflows.
I would expect an AFL fuzzer might do something similar unless you
constrain it.
--
Cheers,
Carlos.