[Dnsmasq-discuss] Potential memory leak

[Matthias Andree]

Am 30.01.26 um 17:33 schrieb Simon Kelley:
> I just sent SIGHUP twice in succession to the dnsmasq process in my 
> OpenWRT router, with the new malloc-logging feature enabled.
>
> HUP frees a load of configuration and the re-reads it and I correlated 
> all the memory freed by the second HUP with what was allocated in the 
> first HUP.
>
> It's perfect. Every block is freed.
>
>
> This is a fairly old installation, so old libraries, etc, but the very 
> latest dnsmasq code.
>
> The configuration it's re-reading is pretty small.
>
> I then tried your technique of hitting dnsmasq hard with many HUPs.
>
> I had to go up to half a million to see much effect, but I guess most 
> of those were dropped since they will have arrived before the previous 
> one was cleared.
>
> In any case I could see a reproducible rise of a few percent in the 
> VSZ of the process each time.
>
> What's clear is that the configuration is stored in a _lot_ of small 
> allocations, so re-reading a substantial configuration  will free a 
> lot of small blocks and then malloc a lot of small blocks.
>
> A quick Google produces some complaints about the fragmentation 
> performance of musl, which may be significant.
>
> Is your installation using musl as the C library, and is it possible 
> to build dnsmasq against, say glibc to test?
>
> Nearly all of the memory management on dnsmasq that gets hit by 
> answering DNS or DHCP requests avoid hammering the malloc system by 
> building pools of free data structures that get re-cycled as needed. 
> Once the pools have grown to equilibrium size, even a very busy server 
> hardly uses the heap. I guess the configuration code to use the same 
> policy, but it's a big re-write, and re-reading configuration on a 
> sub-second timescale is an unlikely use-case.
>
I've built dnsmasq v2.93test2 on Fedora Linux 43 (amd64 aka x86_64) with 
address and undefined behavior sanitizers in GCC and with HAVE_DNSSEC, 
and I am providing three patches (should suit git-am) to fix

* one access past the end of the iovec (reading past the iovcnt limit) 
that triggers AddressSanitizer reproducibly, in read_writev()

* one "variable may be used uninitialized" (I didn't check the logic, I 
just bluntly added = NULL to shut up the compiler) in dnssec code

* one patch that fixes undefined behavior, where base32_decode may shift 
into the sign bit which might wreak havoc on perverse C implementations 
(compiler & processor combination); I didn't test if as alternative, 
making the "oc" an unsigned integer could help, because for unsigned 
integers, wrapping is well-defined, but not for signed integers. We can 
clear the "oc" when we've written it.

I haven't seen a memory leak reported by address sanitizer yet, also 
valgrind in leak-checking mode on FreeBSD didn't holler.

To reproduce, add #define HAVE_DNSSEC to src/config.h, and change these 
three lines in Makefile - this assumes your debugger understands DWARF4 
format and the compiler is reasonably compatible to GCC. You may need to 
tweak ASAN_OPTIONS=detect_leaks=1 to enable leak checking. Note the leak 
checker availability across operating systems is pretty limited. Systems 
that don't have it want to forgo that and use a different leak checker 
(valgrind might work).

> CFLAGS        = -Wall -W -Og -ggdb3 -gdwarf-4 -fno-omit-frame-pointer
> LDFLAGS       = -fsanitize=address,undefined
> COPTS         = -fsanitize=address,undefined
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20260131/9a815a32/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-base32_decode-avoid-shifting-into-the-sign-bit.patch
Type: text/x-patch
Size: 1017 bytes
Desc: not available
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20260131/9a815a32/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-Avoid-uninitialized-value-warnings-from-the-compiler.patch
Type: text/x-patch
Size: 778 bytes
Desc: not available
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20260131/9a815a32/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0003-read_writev-avoid-reading-past-the-last-iovec-elem.patch
Type: text/x-patch
Size: 931 bytes
Desc: not available
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20260131/9a815a32/attachment-0002.bin>