[llvm-demangle-fuzzer] Also fuzz microsoftDemangle().

[morehouse]

Summary

Use first byte of input to determine whether to call itaniumDemangle()
or microsoftDemangle().

Addresses https://bugs.llvm.org/show_bug.cgi?id=39582.

[morehouse]

• Formatting.

[morehouse]

microsoftDemangle crashes in 1 second with buffer overflows or ASSERT failures when I run locally.

[morehouse]

@kcc Ping

[erik.pilkington]

Hi, thanks for working on this! Fuzzing in the itanium demangler has caught *a lot* of bugs, so this seems pretty useful. Whats the argument for testing the two demanglers in the same path? There isn't really any shared code, so I think it makes more sense to separate these out.

@kcc: is there any oss-fuzz testing for llvm-demangle-fuzzer.cpp? I thought it was just for libcxxabi. Also, will reinterpreting the first char in Data break the existing itanium corpuses?

[thakis]

I believe this runs on oss-fuzz already: https://github.com/google/oss-fuzz/blob/master/projects/llvm/build.sh#L37

Having one or two fuzzer binaries seems like a toss-up (true it's a mostly independent branch, but we don't create a new fuzzer binary for each independent branch), and having just binary saves the work of hooking a new binary up on oss-fuzz.

Re corpus: I'd be very surprised if oss-fuzzer assumed that fuzzers never change. So I don't think (but don't know for sure) that this is a concern.

[erik.pilkington]

In D54780#1331426, @thakis wrote:

I believe this runs on oss-fuzz already: https://github.com/google/oss-fuzz/blob/master/projects/llvm/build.sh#L37

Oh, okay nice. Thanks for checking.

Having one or two fuzzer binaries seems like a toss-up (true it's a mostly independent branch, but we don't create a new fuzzer binary for each independent branch), and having just binary saves the work of hooking a new binary up on oss-fuzz.

I would probably prefer always calling microsoftDemangle() in llvm-demangler-fuzzer. The Itanium demanglers are identical, so we're just wasting cycles fuzzing them both independently.

Re corpus: I'd be very surprised if oss-fuzzer assumed that fuzzers never change. So I don't think (but don't know for sure) that this is a concern.

[thakis]

I would probably prefer always calling microsoftDemangle() in llvm-demangler-fuzzer. The Itanium demanglers are identical, so we're just wasting cycles fuzzing them both independently.

That makes sense to me (with a comment explaining this).

[kcc]

I would prefer to have two separate targets.

[morehouse]

• Separate fuzz targets.

[kcc]

LGTM
Don't forget to add the new fuzz target to oss-fuzz

llvm/tools/llvm-demangle-fuzzer/llvm-demangle-fuzzer.cpp

 //===--- llvm-demangle-fuzzer.cpp - Fuzzer for the Itanium Demangler ------===//
 //
 //                     The LLVM Compiler Infrastructure
 //
 // This file is distributed under the University of Illinois Open Source
 // License. See LICENSE.TXT for details.
 //
 //===----------------------------------------------------------------------===//
 
 #include "llvm/Demangle/Demangle.h"
 
 #include <cstdint>
 #include <cstdlib>
 #include <string>
 
 extern "C" int LLVMFuzzerTestOneInput(const uint8_t *Data, size_t Size) {
-  std::string NullTerminatedString((const char *)Data, Size);
-  int status = 0;
-  if (char *demangle = llvm::itaniumDemangle(NullTerminatedString.c_str(), nullptr,
-                                         nullptr, &status))
-    free(demangle);
+  if (Size == 0)
+    return 0;
+
+  std::string NullTerminatedString((const char *)&Data[1], Size - 1);
+  int Status = 0;
+  char *Demangle = nullptr;
+  if (Data[0] < 128)
+    Demangle = llvm::itaniumDemangle(NullTerminatedString.c_str(), nullptr,
+                                     nullptr, &Status);
+  else
+    Demangle = llvm::microsoftDemangle(NullTerminatedString.c_str(), nullptr,
+                                       nullptr, &Status);
+  free(Demangle);
 
   return 0;
 }