``` SCARINESS: 12 (1-byte-read-heap-buffer-overflow) #0 0x557f3a5b5100 in ndpi_get_host_domain /src/ndpi/src/lib/ndpi_domains.c:158:8 #1 0x557f3a59b561 in ndpi_check_dga_name /src/ndpi/src/lib/ndpi_main.c:10412:17 #2 0x557f3a51163a in process_chlo /src/ndpi/src/lib/protocols/quic.c:1467:7 #3 0x557f3a469f4b in LLVMFuzzerTestOneInput /src/ndpi/fuzz/fuzz_quic_get_crypto_data.c:44:7 #4 0x557f3a46abc8 in NaloFuzzerTestOneInput (/out/fuzz_quic_get_crypto_data+0x4cfbc8) ``` Some notes about the leak: if the insertion into the uthash fails (because of an allocation failure), we need to free the just allocated entry. But the only way to check if the `HASH_ADD_*` failed, is to perform a new lookup: a bit costly, but we don't use that code in the fast-path. See also efb261a95c5a Credits for finding the issues to Philippe Antoine (@catenacyber) and his `nallocfuzz` fuzzing engine See: https://github.com/catenacyber/nallocfuzz See: https://github.com/google/oss-fuzz/pull/9902