1. 05 Oct, 2020 1 commit
  2. 17 Oct, 2019 1 commit
  3. 17 Aug, 2019 1 commit
  4. 29 Jul, 2019 1 commit
  5. 20 Jul, 2019 3 commits
  6. 05 Jul, 2019 5 commits
  7. 19 May, 2019 1 commit
  8. 22 Feb, 2019 1 commit
  9. 25 Jan, 2019 1 commit
  10. 22 Jan, 2019 1 commit
  11. 17 Jan, 2019 1 commit
  12. 11 Oct, 2018 3 commits
    • fuzzers: add object parsing fuzzer · a1d5fd06
      Add a simple fuzzer that exercises our object parser code. The fuzzer
      is quite trivial in that it simply passes the input data directly to
      `git_object__from_raw` for each of the four object types.
      Patrick Steinhardt committed
    • fuzzers: initialize libgit2 in standalone driver · 6956a954
      The standalone driver for libgit2's fuzzing targets makes use of
      functions from libgit2 itself. While this is totally fine to do, we need
      to make sure to always have libgit2 initialized via `git_libgit2_init`
      before we call out to any of these. While this happens in most cases as
      we call `LLVMFuzzerInitialize`, which is provided by our fuzzers and
      which right now always calls `git_libgit2_init`, one exception to this
      rule is our error path when not enough arguments have been given. In
      this case, we will call `git_vector_free_deep` without libgit2 having
      been initialized. As we did not set up our allocation functions in that
      case, this will lead to a segmentation fault.
      
      Fix the issue by always initializing and shutting down libgit2 in the
      standalone driver. Note that we cannot let this replace the
      initialization in `LLVMFuzzerInitialize`, as it is required when using
      the "real" fuzzers by LLVM without our standalone driver. It's no
      problem to call the initialization and deinitialization functions
      multiple times, though.
      Patrick Steinhardt committed
  13. 09 Oct, 2018 1 commit
  14. 26 Aug, 2018 1 commit
  15. 16 Aug, 2018 1 commit
  16. 14 Aug, 2018 3 commits
  17. 05 Aug, 2018 2 commits
  18. 03 Aug, 2018 8 commits
    • fuzzers: limit maximum pack object count · e38ddc90
      By default, libgit2 allows up to 2^32 objects when downloading a
      packfile from a remote. For each of these objects, libgit2 will allocate
      up to two small structs, which in total adds up to quite a lot of
      memory. As a result, our fuzzers might run out of memory rather quick in
      case where they receive as input a packfile with such a huge count of
      objects.
      
      Limit the packfile object count to 10M objects. This is sufficiently big
      to still work with most largish repos (linux.git has around 6M objects
      as of now), but small enough to not cause the fuzzer to OOM.
      Patrick Steinhardt committed
    • fuzzers: convert download_refs fuzzer to C · 5db64e2f
      Convert the "download_refs" fuzzer from C++ to C. Rename the source file
      to have it be picked up by our build system.
      Patrick Steinhardt committed
    • fuzzers: import download_refs fuzzer from oss-fuzz · 730c0edb
      This is a direct copy of the code from google/oss-fuzz, written by
      Nelson Elhage (@nelhage). Note that due to the ".cc" ending, the file
      will not yet be picked up by the build system. This is intended, as
      currently that file is partly written in C++, requiring a conversion to
      C.
      Patrick Steinhardt committed
    • fuzzers: avoid use of libgit2 internals in packfile_raw · de53972f
      The packfile_raw fuzzer is using some internal APIs from libgit2, which
      makes it hard to compile it as part of the oss-fuzz project. As oss-fuzz
      requires us to link against the C++ FuzzingEngine library, we cannot use
      "-DBUILD_FUZZERS=ON" directly but instead have to first compile an
      object from our fuzzers and then link against the C++ library. Compiling
      the fuzzer objects thus requires an external invocation of CC, and we
      certainly don't want to do further black magic by adding libgit2's
      private source directory to the header include path.
      
      To fix the issue, convert the code to not use any internal APIs. Besides
      some headers which we have to add now, this also requires us to change
      to the hashing function of the ODB. Note that this will change the
      hashing result, as we have previously not prepended the object header to
      the data that is to be hashed. But this shouldn't matter in practice, as
      we don't care for the hash value anyway.
      Patrick Steinhardt committed
    • cmake: remove need to add "-fsanitize=fuzzer" flag for fuzzers · bf3382d5
      Right now, users are being instrucded to add the
      "-DCMAKE_EXE_LINKER_FLAGS=-fsanitize=fuzzer" flag when they want to
      build our fuzzers. This is error-prone and user unfriendly. Instead,
      just add the flag to our fuzzers' build instructions so that it happens
      automatically. Adjust the README accordingly.
      Patrick Steinhardt committed
    • cmake: use C90 standard for our fuzzing targets · 07cf8b38
      Like all our other internal code, we want to force the use of C90 for
      our fuzzers. Do so by setting the "C_STANDARD" property of our fuzzing
      targets.
      Patrick Steinhardt committed
    • fuzzers: rename "fuzz" directory to match our style · 59328ed8
      Our layout uses names like "examples" or "tests" which is why the "fuzz"
      directory doesn't really fit in here. Rename the directory to be called
      "fuzzers" instead. Furthermore, we rename the fuzzer "fuzz_packfile_raw"
      to "packfile_raw_fuzzer", which is also in line with the already
      existing fuzzer at google/oss-fuzz.
      
      While at it, rename the "packfile_raw" fuzzer to instead just be called
      "packfile" fuzzer.
      Patrick Steinhardt committed