Re: Relying on exceptions in fuzz tests?

That could be because "new" is defined in the language as throwing an
exception if it fails to allocate memory.  Doing a NULL check after "new"
would only be necessary if running in a crippled environment that does not
support exceptions.

Malloc/calloc/realloc should never throw, but return NULL if they fail to
allocate memory.


Chris


On 5/28/14 11:57 PM, "Peter Hillman" <[email protected]> wrote:

> 
> The OpenEXR fuzz tests insert bytes into files to test what happens with
> accidentally or maliciously damaged files.
> When a "length-of-attribute" field in the EXR Header is modified to be
> an extremely large number, the library will often attempt to allocate a
> large amount of memory to load the supposedly large attribute. There's
> no standard place where this happens; each attribute type manages
> loading the values itself. The field storing type of the attribute may
> also become damaged, causing unusual behaviour.
> 
> It seems like the OpenEXR library does rather assume that calls to 'new'
> etc will throw exceptions if they fail, rather than nullptr testing.
> This is in the library itself, rather than the fuzz tests.
> 
> 
> 
> 
> 
> On 29/05/14 13:26, Nick wrote:
>> Are you saying you have a malloc implementation that crashes if it can't
>> allocate due to not enough memory? Or are you saying that the fuzz test
>> relies on an exception not a nullptr test? If the latter it would be better
>> to modify the test to null test. If the former, what the heck?
>> 
>> Fuzz tests generally are supposed to demonstrate that the library can survive
>> malicious exploits like forced overruns or whatever through malformed files.
>> 
>> If you are crashing, it's a bad malloc, a bad test, or OpenEXR isn't
>> completely fuzz safe.
>> 
>> Or this is a different use of the term fuzz testing that I am not familiar
>> with ;)
>> 
>> - Nick
>> 
>> Sent from my iPhone
>> 
>>> On May 28, 2014, at 15:01, "Christopher Horvath" <[email protected]>
>>> wrote:
>>> 
>>> Hey Folks,
>>> 
>>> It seems like some of the fuzz tests are explicitly attempting to fail by
>>> creating large allocations and catching exceptions from failed memory
>>> allocations.  If you're working with a malloc library that has exceptions
>>> turned off, this causes crashes...
>>> 
>>> Is this the correct interpretation of how fuzzScanLines & fuzzFile is
>>> intended to work?
>>> 
>>> This seems to be testing that malloc throws correctly - which in my case, it
>>> does not - I just want to make sure I can feel comfortable turning these
>>> fuzz tests off for the future.
>>> 
>>> Chris
>>> 
>>> -- 
>>> I think this situation absolutely requires that a really futile and stupid
>>> gesture be done on somebody's part. And we're just the guys to do it.
>>> _______________________________________________
>>> Openexr-devel mailing list
>>> [email protected]
>>> https://lists.nongnu.org/mailman/listinfo/openexr-devel
>> _______________________________________________
>> Openexr-devel mailing list
>> [email protected]
>> https://lists.nongnu.org/mailman/listinfo/openexr-devel
> 
> 
> _______________________________________________
> Openexr-devel mailing list
> [email protected]
> https://lists.nongnu.org/mailman/listinfo/openexr-devel