From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.2 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: from second.openwall.net (second.openwall.net [193.110.157.125]) by inbox.vuxu.org (Postfix) with SMTP id D287A28165 for ; Thu, 29 Feb 2024 11:50:07 +0100 (CET) Received: (qmail 19811 invoked by uid 550); 29 Feb 2024 10:46:24 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 19777 invoked from network); 29 Feb 2024 10:46:24 -0000 DKIM-Filter: OpenDKIM Filter v2.11.0 mail.ispras.ru 6460F40737C5 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ispras.ru; s=default; t=1709203793; bh=NIB1zdEC9xpqY6zcoP0MpTgjZBMHaWjF54MPg7MYP2E=; h=Date:From:To:Cc:Subject:Reply-To:In-Reply-To:References:From; b=qaFXUmCx2pOc5vqj3zXPYTQntwBBaaKAD1cHlEJ008LwqeobFe90kiuxEkIXR8d5e lH3mcbX4cP/g1sPX5fYs9W0vooEMGmmiLO2dd0Po9zo5EEB58+qrypGRKTzRUivSpq WMeYkidsxkntsnZSjS9OrxamIzQbZbISulfJYEpA= MIME-Version: 1.0 Date: Thu, 29 Feb 2024 13:49:53 +0300 From: Alexey Izbyshev To: musl@lists.openwall.com Cc: Alexey Kodanev Mail-Followup-To: musl@lists.openwall.com In-Reply-To: <0c7a80b19cf470307d0cc9f2fe1b2d4e@ispras.ru> References: <20230322122916.116088-1-aleksei.kodanev@bell-sw.com> <20230322131651.GW4163@brightrain.aerifal.cx> <0c7a80b19cf470307d0cc9f2fe1b2d4e@ispras.ru> User-Agent: Roundcube Webmail/1.4.13 Message-ID: <45da412c2c78a6d4c02023b172a778aa@ispras.ru> X-Sender: izbyshev@ispras.ru Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [musl] [PATCH] dns: check length field in tcp response message On 2023-05-08 19:25, Alexey Izbyshev wrote: > On 2023-03-22 16:16, Rich Felker wrote: >> On Wed, Mar 22, 2023 at 03:29:16PM +0300, Alexey Kodanev wrote: >>> The received length field in the message may be greater than the >>> size of the 'answer' buffer in which the message resides. Currently, >>> ABUF_SIZE is 768. And if we get a larger 'alen', it will result >>> in an out-of-bounds reading during parsing, because 'alen' will >>> be passed to __dns_parse() later: >>> >>> __dns_parse(abuf[i], alens[i], dns_parse_callback, &ctx); >>> >>> To fix this, limit 'alen' to the size of the received buffer. >>> --- >>> src/network/res_msend.c | 1 + >>> 1 file changed, 1 insertion(+) >>> >>> diff --git a/src/network/res_msend.c b/src/network/res_msend.c >>> index fef7e3a2..291853de 100644 >>> --- a/src/network/res_msend.c >>> +++ b/src/network/res_msend.c >>> @@ -297,6 +297,7 @@ int __res_msend_rc(int nqueries, const unsigned >>> char *const *queries, >>> int rcode = answers[i][3] & 15; >>> if (rcode != 0 && rcode != 3) >>> goto out; >>> + if (alen > asize) alen = asize; >>> >>> /* Storing the length here commits the accepted answer. >>> * Immediately close TCP socket so as not to consume >>> -- >>> 2.25.1 >> >> This is incorrect. It breaks res_send, whose contract is to return the >> full answer length even if it did not fit, so that the caller can >> retry with the appropriate size. >> >> Instead, name_from_dns just needs to clamp the value before passing it >> to __dns_parse. >> > Not only name_from_dns, but also getnameinfo. The patch is attached. > Pinging due to the approaching release. Did the patch fall through cracks? Thanks, Alexey