From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_MSPIKE_H2 autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 9432 invoked from network); 27 Sep 2022 12:20:25 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 27 Sep 2022 12:20:25 -0000 Received: (qmail 11868 invoked by uid 550); 27 Sep 2022 12:20:22 -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 11828 invoked from network); 27 Sep 2022 12:20:21 -0000 Date: Tue, 27 Sep 2022 08:20:05 -0400 From: Rich Felker To: Gabriel Ravier Cc: musl@lists.openwall.com Message-ID: <20220927122005.GG9709@brightrain.aerifal.cx> References: <20220926010339.GA9709@brightrain.aerifal.cx> <20220926220449.GE9709@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] Revisiting LFS64 removal On Tue, Sep 27, 2022 at 11:09:48AM +0200, Gabriel Ravier wrote: > On 9/27/22 00:04, Rich Felker wrote: > >On Sun, Sep 25, 2022 at 09:03:40PM -0400, Rich Felker wrote: > >>[...] > >>Of course these interfaces should not be used, and we never intended > >>for them to be used just there for linking-compat. So, I've wanted to > >>get rid of them for a long time now. > >> > >>I believe the simplest short-term way is probably going to be just > >>having the dynamic linker symbol lookup error path make one final > >>check before bailing out with an error: > >> > >>- If the symbol to lookup ends in "64".. > >>- ..and it's in a hard-coded list of LFS64-compat symbols.. > >>- ..and looking up the name with the "64" removed in libc succeeds.. > >> > >>Then use the version without the "64" suffix and go on with relocation > >>processing. > >Proposed patch attached. > > > Looks at though the patch contains a buffer overflow to me, as the > length of `name` appears to be unbounded, but it's then copied into > `buf` which has its size limited to 16, all without checking for `l > >= sizeof buf` until after the copying is done (which might just > even get optimized out by GCC since it knows `l` can't be larger > than buf without UB occuring) Thanks for the catch! It was a late change I made to avoid re-iterating but indeed it's wrong. (Note that strlen, etc. can't be used here because external function calls or even references are not valid in the context this can be called in; strcmp is a macro that expands to a static function call.) Rich