public inbox for libc-help@sourceware.org
 help / color / mirror / Atom feed
From: Charalampos Mitrodimas <charmitro@posteo.net>
To: libc-help@sourceware.org
Subject: Potential Memory Leak in libc DNS Resolution Functions
Date: Sat, 10 Feb 2024 15:22:16 +0000	[thread overview]
Message-ID: <5a2a1ca4-ebcb-45ea-9b55-ba3f890478b1@posteo.net> (raw)

Hello,

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)
    ==4151==    by 0x4DBD85E: __resolv_conf_get_current (resolv_conf.c:140)
    ==4151==    by 0x4DB9394: __res_vinit (res_init.c:628)
    ==4151==    by 0x4DBE82F: maybe_init (resolv_context.c:122)
    ==4151==    by 0x4DBE82F: context_get (resolv_context.c:184)
    ==4151==    by 0x4DBE82F: context_get (resolv_context.c:176)
    ==4151==    by 0x4DBE82F: __resolv_context_get (resolv_context.c:195)
    ==4151==    by 0x4D78C87: get_nss_addresses (getaddrinfo.c:617)
    ==4151==    by 0x4D78C87: gaih_inet (getaddrinfo.c:1179)
    ==4151==    by 0x4D78C87: getaddrinfo (getaddrinfo.c:2397)
    ==4151==    by 0x4A7108E: <std::sys_common::net::LookupHost as 
core::convert::TryFrom<(&str,u16)>>::try_from::{{closure}} (net.rs:207)
    ==4151==    by 0x4A6A105: <(&str,u16) as 
std::net::socket_addr::ToSocketAddrs>::to_socket_addrs 
(small_c_string.rs:43)
    ==4151==    by 0x495356A: 
lettre::transport::smtp::client::net::NetworkStream::connect::try_connect 
(net.rs:104)
    ==4151==    by 0x49532F1: 
lettre::transport::smtp::client::net::NetworkStream::connect (net.rs:139)

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.

Thank you for your support.

           Charalampos Mitrodimas


             reply	other threads:[~2024-02-10 15:22 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-10 15:22 Charalampos Mitrodimas [this message]
2024-02-11 12:04 ` Florian Weimer
2024-02-12 15:53   ` Charalampos Mitrodimas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5a2a1ca4-ebcb-45ea-9b55-ba3f890478b1@posteo.net \
    --to=charmitro@posteo.net \
    --cc=libc-help@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).