From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gnu.wildebeest.org (gnu.wildebeest.org [45.83.234.184]) by sourceware.org (Postfix) with ESMTPS id 4CC933858D1E for ; Tue, 14 Feb 2023 15:44:31 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 4CC933858D1E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=klomp.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=klomp.org Received: from r6.localdomain (82-217-174-174.cable.dynamic.v4.ziggo.nl [82.217.174.174]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gnu.wildebeest.org (Postfix) with ESMTPSA id 30B3430067DA; Tue, 14 Feb 2023 16:44:29 +0100 (CET) Received: by r6.localdomain (Postfix, from userid 1000) id 37F4F34034E; Tue, 14 Feb 2023 16:44:29 +0100 (CET) Message-ID: <483ee8b69013951e9668a1c7b3bee708aebaa560.camel@klomp.org> Subject: Re: [PATCH v2] libdw: check memory access in get_(u|s)leb128 From: Mark Wielaard To: vvvvvv@google.com Cc: elfutils-devel@sourceware.org, kernel-team@android.com, maennich@google.com Date: Tue, 14 Feb 2023 16:44:29 +0100 In-Reply-To: <20230213201005.2498216-1-vvvvvv@google.com> References: <20230213201005.2498216-1-vvvvvv@google.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.46.3 (3.46.3-1.fc37) MIME-Version: 1.0 X-Spam-Status: No, score=-3029.6 required=5.0 tests=BAYES_00,JMQ_SPF_NEUTRAL,KAM_DMARC_STATUS,KAM_NUMSUBJECT,RCVD_IN_BARRACUDACENTRAL,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=no 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 Aleksei, On Mon, 2023-02-13 at 20:10 +0000, Aleksei Vetrov via Elfutils-devel wrote: > __libdw_get_uleb128 and __libdw_get_sleb128 should check if addrp has > already reached the end before unrolling the first step. It is done by > moving __libdw_max_len to the beginning of the function, which can > notice, that addrp is beyond the end. Then we just check the result of > this function. This looks good. And I couldn't measure any meaningful performance difference. Pushed. Even though this now catches all calls that have start >=3D end, I'll also push my other patch to add extra guards in the callers of get_(u|s)leb128, because that does provide us with better error messages. Thanks, Mark