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.