mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@libc.org>
To: Gabriel Ravier <gabravier@gmail.com>
Cc: musl@lists.openwall.com
Subject: Re: [musl] Revisiting LFS64 removal
Date: Tue, 27 Sep 2022 08:20:05 -0400	[thread overview]
Message-ID: <20220927122005.GG9709@brightrain.aerifal.cx> (raw)
In-Reply-To: <bed3d35e-1598-8ad6-4150-741517ecee4b@gmail.com>

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

  reply	other threads:[~2022-09-27 12:20 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-26  1:03 Rich Felker
2022-09-26 16:03 ` Markus Wichmann
2022-09-26 16:47   ` Rich Felker
2022-09-26 22:04 ` Rich Felker
2022-09-27  9:09   ` Gabriel Ravier
2022-09-27 12:20     ` Rich Felker [this message]
2022-09-27 19:03       ` Rich Felker
2022-09-27 19:08         ` Rich Felker
2022-09-29 23:07           ` Rich Felker
2022-09-30  2:44             ` Markus Wichmann
2022-09-30 12:57               ` Rich Felker
2022-09-30 17:35                 ` Colin Cross
2022-09-30 18:13                   ` enh
2022-09-30 19:26                     ` Rich Felker
2022-09-30 23:03                       ` enh
2022-09-30 19:29                   ` Rich Felker
2022-09-30 19:41                     ` Rich Felker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220927122005.GG9709@brightrain.aerifal.cx \
    --to=dalias@libc.org \
    --cc=gabravier@gmail.com \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).