Re: [PATCH 04/14] fuzz/x86_emulate: Add a better input size check

From: George Dunlap <george.dunlap@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Cc: xen-devel <xen-devel@lists.xenproject.org>,
	Ian Jackson <ian.jackson@citrix.com>,
	Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>
Subject: Re: [PATCH 04/14] fuzz/x86_emulate: Add a better input size check
Date: Mon, 25 Sep 2017 12:08:32 +0100	[thread overview]
Message-ID: <CAFLBxZafK=XfVN=UB4g8_TZgNjAWNMjZHyQW-hzbKSLR3+_WsQ@mail.gmail.com> (raw)
In-Reply-To: <CAFLBxZZ6FGku1VxxQbq6XOsmRHEohXzwkXmMtLprfMgm35Nf2A@mail.gmail.com>

On Mon, Sep 25, 2017 at 10:36 AM, George Dunlap
<george.dunlap@citrix.com> wrote:
> On Fri, Sep 15, 2017 at 12:39 PM, Wei Liu <wei.liu2@citrix.com> wrote:
>> On Fri, Aug 25, 2017 at 05:43:33PM +0100, George Dunlap wrote:
>>> For some reason the 'feof()' check for the file size isn't working in
>>> llvm-clang-fast mode; the result is several kilobyte files rather than
>>> the 4k limit files as we've requested.  This is bad in part because
>>> AFL will spend time trying to "fuzz" bits of the input that are never
>>> touched.
>>>
>>
>> You mean feof returns non-zero (true) when it shouldn't?
>
> It looks like it does.  I modified the code thus:
>
>         if ( !feof(fp) )
>         {
>             printf("Input too large\n");
>             if ( optind + 1 ==  argc )
>                 exit(-1);
>             continue;
>         }
>
>         if ( fread(input, 1, 1, fp) > 0 )
>         {
>             fprintf(stderr, "feof check failed to detect oversized input!");
>             abort();
>         }
>
> And ran AFL for a bit in afl-clang-fast mode.  It ran fine for about
> two cycles, before the massive repetition started happening; but once
> the file size got larger than 4096 it found "crashes", even though
> running it manually with the same input file results in a simple
> "Input too large".

Actually -- I had forgotten that over the weekend I came up with
another hypothesis: The reason feof() is returning true even when
we're not at an EOF is that we haven't called clearerr() on the
previous iteration.

Testing now with clearerr() -- if that works I'll send a patch that
fixes the root problem.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel