Go software can exhibit a variety of denial-of-service bugs such as slice out-of-bounds access (since there is no try/catch mechanism, this leads to a panic), excessive allocations, excessive computation/timeout (consider "for i := 0; i < N; i++" where N is untrusted), stack overflow due to unbounded recursion (rare because Go has a custom, large stack).
My bignum-fuzzer project [1] runs on oss-fuzz and tries to find mismatches between bignum computations across different libraries (OpenSSL, Go, Rust, etc). This is one example of how fuzzing can be useful even if the underlying language is "safe".
With some small hacks you can also have Go code coverage instrumentation as a libFuzzer counter.
Comments
Go software can exhibit a variety of denial-of-service bugs such as slice out-of-bounds access (since there is no try/catch mechanism, this leads to a panic), excessive allocations, excessive computation/timeout (consider "for i := 0; i < N; i++" where N is untrusted), stack overflow due to unbounded recursion (rare because Go has a custom, large stack).
My bignum-fuzzer project [1] runs on oss-fuzz and tries to find mismatches between bignum computations across different libraries (OpenSSL, Go, Rust, etc). This is one example of how fuzzing can be useful even if the underlying language is "safe".
With some small hacks you can also have Go code coverage instrumentation as a libFuzzer counter.
[1] https://github.com/guidovranken/bignum-fuzzer/blob/master/mo...
And Go isn't memory safe given race conditions.
If you're using goroutines you may want to consider fuzzing with the race detector.
That's a nice explanation, thank you. I'll take a look at implementing it in some small piece of software :)