A heap-based buffer overflow in answer_request (called from FuzzAnswerTheRequest and fuzz_rfc1035.c). Reference: https://github.com/google/oss-fuzz-vulns/blob/main/vulns/dnsmasq/OSV-2021-935.yaml https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=35920
Created dnsmasq tracking bugs for this issue: Affects: fedora-all [bug 2048922]
I have attempted to build dnsmasq fuzzers directly [1]. It is a bit unstable, but from issues I were able to reproduce so far on it and debug with gdb, extract_name often fails because insufficient daemon->namebuff buffer is used on fuzzing. It is error in fuzzer, not real dnsmasq code. I admit there is problem with how dnsmasq prepares its structures, that initialization is not well structured. gb_get_null_terminated allocates only 76 large buffer for given string. If extract_name uses this string as target of name, it would fail on cp-name == 76. Those cannot ever happen. Dnsmasq code often relies on some size constants of used buffers defined somewhere else. It is guaranteed daemon->namebuff is either MAXDNAME long or 2*MAXDNAME in case of DNSSEC build enabled. When I fixed that in my fuzzers[2], it did not yet find any crashing issue. oss-fuzz seems to have this wrong [3]. I admit it might significantly slow down fuzzing process, but might filter out bogus cases. daemon->namebuff is allocated on the start of read_opts() in src/option.c in real dnsmasq. 1. https://github.com/InfrastructureServices/dnsmasq/tree/oss-fuzz/fuzz 2. https://github.com/InfrastructureServices/dnsmasq/commit/28e9a0ed9ee9052f285f20b8db9a02897a452c11 3. https://github.com/google/oss-fuzz/blob/6a54a7b965efe331d8c2e023a51317da256aafff/projects/dnsmasq/fuzz_header.h#L238
I think issues in extract_name are caused by insufficient buffer prepared by fuzzer code. It does not detect problem in dnsmasq, but problem in fuzzer code instead. When I increased size of buffer to match size of dnsmasq allocated buffer, it does not crash anymore. Changed code in PR [1]. 1. https://github.com/google/oss-fuzz/pull/7293