Multiple crashes when dealing with corrupt data

[debrouxl]

Copying the bulk of an e-mail I sent 10 days ago into public issues on this repo :)

I tried to fuzz the library through its CLI front-end, to make a quick assessment of its robustness, and I've found lots of issues. Data corruption sometimes happens in the real world.
I've fuzzed several dozens of code bases over the years, all of them being written in memory-unsafe C and/or C++, and unsurprisingly, all but one fell quickly to zzuf, afl and/or honggfuzz. For libGDSII, configuring + building with CC/CXX=afl-clang-fast and starting a fuzzing job took less than 15 minutes.

You'll find the offending files in the "output" folder from the attached tarball:
libgdsii_fuzz_afl_20190817.tar.gz

As hinted above, the results, are... not pretty:

1. the time to first crash, with an abysmal file corpus (single 0-byte file !), is around a second;
2. adding the bend-flux.gds file from the libGDSII repo produced several dozen "unique" crashes (multiple "unique" crashes can have the same final stack trace, but they went through different paths at some point, IIUC) in less than a minute;
3. adding a simple dictionary containing the codes listed at http://www.idea2ic.com/PlayWithICEDIT/Look_Inside_GDSII.html further raises the initial discovery rate for crashes.
   There are multiple paths causing nullptr dereferences, so while the AddressSanitizer instrumentation (AFL_USE_ASAN=1 make ...) did find OOB accesses worth fixing, OOB accesses which wouldn't always crash in a normal build are not the leading cause of crashes.

Some of the crashers are less than 10 bytes large, e.g. the following hex dumps:

00 00 04 00
00 04 17 01

Nothing special about the afl-fuzz invocation:

$ .../afl-fuzz -i input -o output -m none -M 1 -e gds -- .../GDSIIConvert @@ --analyze

The -e option only works with AFL++'s afl-fuzz. I could also have attempted to patch out the extension check.

The first fuzzing round finds enough issues, quickly enough, to warrant a second one, possibly using honggfuzz instead, for a change. Also, maybe more modes of GDSIIConvert, to exercise more code paths.
If you have, say, several dozen to several hundred valid small GDSII files, ranging from several bytes to ideally less than 1 KB, which use the various GDS-II codes - effectively, something like a test suite for a library like libGDSII - that would help :)