Concept ACK - will be sure to try this out.

@Crypt-iQ I don't have any Mac to test on, so I'm afraid I cannot help much. Could you add an assertion in PeerManager::ProcessMessage to make sure you're hitting the relevant code paths? :)

Do you have any Linux machine to test under? :)

Testing on an Ubuntu machine now.

With this method of fuzzing, I think honggfuzz has to guess the handshake by picking multiple correct inputs/messages?

@Crypt-iQ That is correct (unless we bypass the handshake logic by manually patching it out too)! However, my experience is that Honggfuzz quickly figures that out and achieves meaningful coverage post-handshake. Is that your experience as well? :)

Are crashes reproducible? I guess they might happen to, but generally might require all seeds that have been sent in the past?

@MarcoFalke

Theoretically both types of issues are certainly possible: reproducible (single input enough to trigger condition) and "non-reproducible" (in this context: single input + previous inputs needed to trigger condition).

Practically:

If this fuzzer hits any issues my guess is that such issues will be reproducible with high probability. That has been the case historically with issues uncovered by src/test/fuzz/process_message or src/test/fuzz/process_messages. They have typically not been dependent on a specific state change being cause by previously proceed input.

Does that answer your question? :)

The reason is that process_messages sends all messages in one input/seed. This one might split them into multiple seeds.

@MarcoFalke I'm not sure I follow TBH. In the case of HonggFuzz NetDriver each input is handled as if it was a new incoming TCP connection, and each input can contain multiple messages (Bitcoin P2P messages).

The TCP connection is not re-used across inputs if that is what you meant :)

Reports a signed integer overflow here:

net_processing.cpp:2651:37: runtime error: signed integer overflow: -9223372036854775808 - 1612058654 cannot be represented in type 'long'
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior net_processing.cpp:2651:37 in

Given @Crypt-iQ's finding above the value of having Honggfuzz NetDriver in the fuzzing toolbox has been proven empirically I guess :)

Is there anything left to do for this documentation only PR?

I had to comment out the following line before building honggfuzz as otherwise it would stop on my 2015 macbook Arch Linux citing slow execution. Could be the age of my computer though. I bumped the timeout as some of the seeds took >4 seconds, and could not use multiple threads due to a lock on the data directory.

https://github.com/google/honggfuzz/blob/e2acee785aa87a86261c96070cf51b85533257ca/libhfuzz/persistent.c#L78

Sorry to gravedig, but I found out why honggfuzz can't get past the version-verack handshake on my machine. Compiling with honggfuzz and -fsanitize=address doesn't instrument strncmp on my build, so it can't guess the message commands. I tried with a very simple external testcase (guess "foo" and panic program) to be sure, and it got stuck.

@Crypt-iQ Could using a dictionary file containing the commands help overcome that fuzzing hurdle?