Re: Potential Memory Leak in libc DNS Resolution Functions

[Charalampos Mitrodimas <charmitro@posteo.net>]

Hi Florian,

On 2/11/24 14:04, Florian Weimer wrote:
> * Charalampos Mitrodimas via Libc-help:
>
>> I've encountered a potential memory leak in libc, specifically within
>> the DNS resolution functions, as identified by Valgrind. The leak
>> involves __libc_alloc_buffer_allocate and related functions. Here's the
>> Valgrind output snippet:
>>
>>     ==4151== 156 bytes in 1 blocks are definitely lost in loss record
>> 730 of 1,029
>>     ==4151==    at 0x4848899: malloc (in
>> /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
>>     ==4151==    by 0x4D15048: __libc_alloc_buffer_allocate
>> (alloc_buffer_allocate.c:26)
>>     ==4151==    by 0x4DBDC65: alloc_buffer_allocate (alloc_buffer.h:143)
>>     ==4151==    by 0x4DBDC65: __resolv_conf_allocate (resolv_conf.c:391)
>>     ==4151==    by 0x4DB8D0A: __resolv_conf_load (res_init.c:599)
> This is unfortunately not very illuminating because the struct
> resolv_conf functions are reference-counted.  If there's a counter
> management bug somewhere, it would be reported like this by valgrind.
>
>> This issue arose in an application using Rust's email library Lettre,
>> ultimately traced back to libc during DNS resolution. Could you please
>> advise if this is a known issue and recommend any steps to address it?
>> I'm willing to contribute a fix, but want to make sure this is of
>> concern for the libc team, before starting the investigation.
> I don't recall a problem like this being reported before.  Can you
> reproduce it on a recent glibc version?  We have some cases of
> known/intended leaks (if the memory that can be leaked is bounded for
> the life-time of the process), but that doesn't apply here.  It
> certainly looks like something we'd want to fix.

Thanks for replying!

Yes, I'll try to provide more information, debug different
versions and reach back.