Using tar is a fine trick. But It will also stress tar itself and will waste some time on it.

We don't have a really easy way to fuzz combinations of multiple
inputs. However, we have a way to implement more custom logic,
including your own custom mutators. See
https://github.com/llvm-mirror/llvm/blob/master/lib/Fuzzer/test/UserSuppliedFuzzerTest.cpp

There the target function is not just a function, but a member of a class which also redefines the Mutate method.
So, in your custom mutator you may
  - untar the file (which is a valid tar archive)
  - mutate every file in the archive separately
  - tar it back for storage.

We don't have a more convenient way yet, but your request is not unique.

This was found while working on extending ftfuzzer.cc for libFuzzer, but appears to happen naturally (I haven't even started running the fuzzer with these changes yet, just testing with runinput).

The attached fuzzer_add_tar_support.diff is an experimental attempt to add 'tar' as an input format so that the fuzzer can provide multiple 'files' as input. Note that this requires libarchive headers to be available. If the data cannot be decoded as 'tar' it just uses the whole file as input. If the data can be decoded as 'tar' then the first file is used to create the face, and the rest are attached to the face. This should allow at least some fuzzing of pfb/afm/pfm fonts.

The attached a010013l.tar file was created on an Ubuntu box with the gsfonts package installed (these appear to be GPL with font exception) by running

tar -cf a010013l.tar /usr/share/fonts/type1/gsfonts/a010013l.pfb /usr/share/fonts/type1/gsfonts/a010013l.afm /usr/share/fonts/type1/gsfonts/a010013l.pfm

note that the pfb needs to be first here.


Introduction aside, this detected a leak on the first test run (with what looks like valid input). The leak is reported as:

ERROR: LeakSanitizer: detected memory leaks

Direct leak of 88 byte(s) in 1 object(s) allocated from:
    #0 0x4ade2b in __interceptor_malloc src/llvm_all/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:40:3
    #1 0x5e9191 in ft_mem_qalloc src/freetype2/src/base/ftutil.c:76:15
    #2 0x5e9191 in ft_mem_alloc src/freetype2/src/base/ftutil.c:55
    #3 0x841c29 in T1_Read_Metrics src/freetype2/src/type1/t1afm.c:245:10
    #4 0x5fd7a6 in FT_Attach_Stream src/freetype2/src/base/ftobjs.c:2397:15
    #5 0x4d966f in LLVMFuzzerTestOneInput src/freetype2/src/tools/ftfuzzer/ftfuzzer.cc:200:11
    #6 0x4eaa6b in main src/freetype2/src/tools/ftfuzzer/runinput.cc:37:7
    #7 0x7ffff60a7ec4 in __libc_start_main /build/buildd/eglibc-2.19/csu/libc-start.c:287

Indirect leak of 15728 byte(s) in 1 object(s) allocated from:
    #0 0x4ade2b in __interceptor_malloc src/llvm_all/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:40:3
    #1 0x637bc1 in ft_mem_qalloc src/freetype2/src/base/ftutil.c:76:15
    #2 0x637bc1 in ft_mem_alloc src/freetype2/src/base/ftutil.c:55
    #3 0x637bc1 in ft_mem_qrealloc src/freetype2/src/base/ftutil.c:146
    #4 0x5ea13e in ft_mem_realloc src/freetype2/src/base/ftutil.c:102:13
    #5 0x6fbfc0 in afm_parse_kern_pairs src/freetype2/src/psaux/afmparse.c:714:12
    #6 0x6fbfc0 in afm_parse_kern_data src/freetype2/src/psaux/afmparse.c:807
    #7 0x6fbfc0 in afm_parser_parse src/freetype2/src/psaux/afmparse.c:951
    #8 0x841fff in T1_Read_Metrics src/freetype2/src/type1/t1afm.c:267:17
    #9 0x5fd7a6 in FT_Attach_Stream src/freetype2/src/base/ftobjs.c:2397:15
    #10 0x4d966f in LLVMFuzzerTestOneInput src/freetype2/src/tools/ftfuzzer/ftfuzzer.cc:200:11
    #11 0x4eaa6b in main src/freetype2/src/tools/ftfuzzer/runinput.cc:37:7
    #12 0x7ffff60a7ec4 in __libc_start_main /build/buildd/eglibc-2.19/csu/libc-start.c:287

I think what is happening here is that I've attached both an afm and a pfm, so the first one leaks when the second is applied.