[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <bed3d35e-1598-8ad6-4150-741517ecee4b@gmail.com>
Date: Tue, 27 Sep 2022 11:09:48 +0200
From: Gabriel Ravier <gabravier@...il.com>
To: musl@...ts.openwall.com, Rich Felker <dalias@...c.org>
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.
