From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout01.posteo.de (mout01.posteo.de [185.67.36.65]) by sourceware.org (Postfix) with ESMTPS id 2F8AB3858D32 for ; Mon, 12 Feb 2024 15:53:53 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 2F8AB3858D32 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=posteo.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=posteo.net ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 2F8AB3858D32 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=185.67.36.65 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1707753235; cv=none; b=WU7Yp3fwlB9dzl5Ia51+qdjbfn8Otdes8vZH0BH0/DPKSuXqhmTBwbIimr+/pqx6nn2+XWUpy1bKDGDa3DdeDBNP1VRdt1bomm1ZAv4B9vEYHGjlF35tTS83s+K4BVpJB1loGi7KLTeJBIz1UYDOHxZido2xdtN8vy+Exr6q4S0= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1707753235; c=relaxed/simple; bh=vm1Y/WMsgkse28MFj7sGulBN/LEY07xAtcRcQedPGYQ=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=r5Tpd7bpFTD/4DnaoboxWgSD+XtDKGGWHZtn1/lAlVTulJx8/HdLn3Lb1ocUIMBa6X8qX9PWHQph/zen+KaCQ/R2QVxpgRg6qubOYbpDOS/lxHkEvcOXjo1+Klvz+uQRvcPHfIzRbsVk9aTwZB5T4vStyq7D7JEBHeFkgchoHd0= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id A5055240027 for ; Mon, 12 Feb 2024 16:53:50 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1707753230; bh=vm1Y/WMsgkse28MFj7sGulBN/LEY07xAtcRcQedPGYQ=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:From:Content-Type: Content-Transfer-Encoding:From; b=TO0na7/NpjmFFcjnM02fx+if4ymbAMPavKwuzanYBEy7XrloOBNCZNt6PDE+eady1 5ICke6CSDf1uWYBbbsChTzOeh2NvBKlI29LuHPDKHuqR6JZRfCzCn7AOzs1fV2UxEh 7Asd1KGH/pOsFiawT0y6BWNw5JgGeXTK8FBZWGk2B18tsjjEL2fQ8AmE5KsR5FpuEN Lht/I4A1OQ8kH7ASACP1B4WZ78tSz+PIvT6j47tecZdxycqdBbOoX+bYANeqKQ4zBw MhVr6QIzOcxfKubC0hK5Ew/u1qid54v7efebniWrxubMxK0d8jDVo3hkHENeBds8fW PcIUiMxtX/6Pw== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4TYTXF5tmFz6twM; Mon, 12 Feb 2024 16:53:49 +0100 (CET) Message-ID: Date: Mon, 12 Feb 2024 15:53:49 +0000 MIME-Version: 1.0 Subject: Re: Potential Memory Leak in libc DNS Resolution Functions Content-Language: en-US To: Charalampos Mitrodimas via Libc-help References: <5a2a1ca4-ebcb-45ea-9b55-ba3f890478b1@posteo.net> <87zfw7yzp2.fsf@oldenburg.str.redhat.com> Cc: Florian Weimer From: Charalampos Mitrodimas In-Reply-To: <87zfw7yzp2.fsf@oldenburg.str.redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: 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.