From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id D7C8A3858D20 for ; Fri, 4 Feb 2022 12:06:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D7C8A3858D20 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-380-0EETPVwcMOW2N3T9p7eG3A-1; Fri, 04 Feb 2022 07:06:43 -0500 X-MC-Unique: 0EETPVwcMOW2N3T9p7eG3A-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 8F9FA1091DA0; Fri, 4 Feb 2022 12:06:42 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.39.193.205]) by smtp.corp.redhat.com (Postfix) with ESMTPS id B679E7CAE0; Fri, 4 Feb 2022 12:06:41 +0000 (UTC) From: Florian Weimer To: Siddhesh Poyarekar via Libc-alpha Cc: Siddhesh Poyarekar Subject: Re: [PATCH] getaddrinfo: Fix leak with AI_ALL [BZ #28852] References: <20220202163902.3596109-1-siddhesh@sourceware.org> Date: Fri, 04 Feb 2022 13:06:39 +0100 In-Reply-To: <20220202163902.3596109-1-siddhesh@sourceware.org> (Siddhesh Poyarekar via Libc-alpha's message of "Wed, 2 Feb 2022 22:09:02 +0530") Message-ID: <87y22qq1io.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-12.2 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2022 12:06:45 -0000 * Siddhesh Poyarekar via Libc-alpha: > diff --git a/sysdeps/posix/getaddrinfo.c b/sysdeps/posix/getaddrinfo.c > index 18dccd5924..652a1a43d4 100644 > --- a/sysdeps/posix/getaddrinfo.c > +++ b/sysdeps/posix/getaddrinfo.c > @@ -199,9 +199,6 @@ convert_hostent_to_gaih_addrtuple (const struct addri= nfo *req, > =09=09=09=09 struct hostent *h, > =09=09=09=09 struct gaih_addrtuple **result) > { > - while (*result) > - result =3D &(*result)->next; > - > /* Count the number of addresses in h->h_addr_list. */ > size_t count =3D 0; > for (char **p =3D h->h_addr_list; *p !=3D NULL; ++p) > @@ -212,10 +209,30 @@ convert_hostent_to_gaih_addrtuple (const struct add= rinfo *req, > if (count =3D=3D 0 || h->h_length > sizeof (((struct gaih_addrtuple) {= }).addr)) > return true; > =20 > - struct gaih_addrtuple *array =3D calloc (count, sizeof (*array)); > + struct gaih_addrtuple *array =3D *result; > + size_t old =3D 0; > + > + while (array) > + { > + old++; > + array =3D array->next; > + } > + > + array =3D realloc (*result, (old + count) * sizeof (*array)); > + > if (array =3D=3D NULL) > return false; > =20 > + *result =3D array; > + > + /* Update the next pointers on reallocation. */ > + for (size_t i =3D 0; i < old; i++) > + array[i].next =3D array + i + 1; > + > + array +=3D old; > + > + memset (array, 0, count * sizeof (*array)); > + > for (size_t i =3D 0; i < count; ++i) > { > if (family =3D=3D AF_INET && req->ai_family =3D=3D AF_INET6) > @@ -235,7 +252,6 @@ convert_hostent_to_gaih_addrtuple (const struct addri= nfo *req, > array[0].name =3D h->h_name; > array[count - 1].next =3D NULL; > =20 > - *result =3D array; > return true; > } I think this assumes that the addrmem block (now managed by realloc) is always at the end of the =E2=80=9Cat=E2=80=9D tuples list (which is not alw= ays backed by addrmem memory). If that is not the case, the tail after the addrmem block is lost. Reading the code, I can't really see if this assumption is true or not. 8-( Thanks, Florian