Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 27 Sep 2022 11:09:48 +0200
From: Gabriel Ravier <>
To:, Rich Felker <>
Subject: Re: Revisiting LFS64 removal

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)

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.