Wouldn't we want curl to function as close as possible to normal when fuzzing? In other words are these FUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION blocks really necessary

Fuzz targets are allowed to make concessions if it would improve the overall fuzzing effort. For example, some fuzzers disable randomness so that things are more deterministic.

This fix wouldn't fundamentally change the function here. There is no need for the curl_multi_init() function to use so many hash entries; it will use a single connection in its lifetime. Setting up hundreds of hash entries is an unnecessary overhead.

(I have however found another fix to the fuzzer which has sped it up by a significant margin, so this fix is now less important)

The code is written to allow CURL_SOCKET_HASH_TABLE_SIZE to be changed at build-time without requiring any code change:

CPPFLAGS=-DCURL_SOCKET_HASH_TABLE_SIZE=13 ./configure

I wouldn't mind changing the code to allow the same thing for CURL_CONNECTION_HASH_SIZE.

I think that's a much nicer approach.

Happy to do that - didn't realise that CURL_SOCKET_HASH_TABLE_SIZE could be overridden.

Change proposed by @bagder now made.

thanks!