fuzz: add allocations failures

[catenacyber]

Nalloc fuzzing had found #470

Now, it can be integrated with a single file

The fuzz target injects allocations failures.
These are enabled if the fuzz target name ends with _nalloc or if NALLOC_FREQ env variable is defined (to 32 for default behavior)

[ctruta]

Thank you for this contribution, @catenacyber. Considering how nalloc proved its value with PR #470, I am keen to integrate it into libpng fuzzing more systematically.

With the important mention that I am by no means an expert in fuzz testing, I'd like to ask a few questions about the triage workflow and about the OSS-Fuzz integration.

About the triage workflow:

• When a crash occurs, how do we distinguish genuine bugs (missing NULL checks, UAF in cleanup) from expected behavior (libpng correctly errors out but the harness doesn't handle it)?
• Are there any tooling or tips for reproducing or even minimizing the nalloc-triggered crashes?

About the OSS-Fuzz integration:

• Is this intended to run within libpng's existing OSS-Fuzz project? If so, has Google's infrastructure been validated with this technique?
• Separate target, or augmenting the existing libpng_read_fuzzer?

And, finally, the last questions fall into "just curious" category -- but please indulge me :-)

• How does NALLOC_FREQ=32 work — probabilistic (1-in-32 chance) or deterministic (fail every 32nd allocation)?
• Any global state or thread-safety considerations?

[catenacyber]

• When a crash occurs, how do we distinguish genuine bugs (missing NULL checks, UAF in cleanup) from expected behavior (libpng correctly errors out but the harness doesn't handle it)?

You get a regular stack trace as usual.
When running with env variable NALLOC_VERBOSE set, you also get the stack trace of failed allocation

• Are there any tooling or tips for reproducing or even minimizing the nalloc-triggered crashes?

There is the usual tool -minimize_crash of libFuzzer, but this may not work so well indeed here.
We should need to indicate which allocation we want to pin to failure when minimizing, but that is not simple...

About the OSS-Fuzz integration:

• Is this intended to run within libpng's existing OSS-Fuzz project? If so, has Google's infrastructure been validated with this technique?

Yes it is. There are some projects that already run this : libwebp, libssh...

• Separate target, or augmenting the existing libpng_read_fuzzer?

We can do either, but people preferred a separate target

And, finally, the last questions fall into "just curious" category -- but please indulge me :-)

• How does NALLOC_FREQ=32 work — probabilistic (1-in-32 chance) or deterministic (fail every 32nd allocation)?

This is a special value, where each run gets a different frequency for allocation failure

• Any global state or thread-safety considerations?

I do not think so, I did not see any problems so far. The usage of __thread unsigned int should make it ok

[ctruta]

@catenacyber thank you for your contribution, and for your explanations also. I edited the commit message to include these explanations (which I consider valuable) and I integrated your commit.

[catenacyber]

Thanks, I added #767

Because now you can build and run the fuzz target with allocations failures, but oss-fuzz does not yet