mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@libc.org>
To: musl@lists.openwall.com
Subject: Re: [PATCH] dl_addr: compare addr with sym->st_size.
Date: Thu, 12 Apr 2018 21:01:52 -0400	[thread overview]
Message-ID: <20180413010152.GS3094@brightrain.aerifal.cx> (raw)
In-Reply-To: <a6d31df49bab482390c8efc3eb727251@sap.com>

On Wed, Apr 11, 2018 at 08:07:38AM +0000, Siebenborn, Axel wrote:
> Hi,
> > -----Original Message-----
> > From: Rich Felker [mailto:dalias@aerifal.cx] On Behalf Of Rich Felker
> > Sent: Dienstag, 10. April 2018 16:23
> > To: musl@lists.openwall.com
> > Subject: Re: [musl] [PATCH] dl_addr: compare addr with sym->st_size.
> > 
> > On Tue, Apr 03, 2018 at 01:06:09PM +0000, Siebenborn, Axel wrote:
> > > Hi,
> > > this patch fixes a problem with dl_addr.
> > >
> > > We found symbols, in cases we should not find a symbol, since the
> > > comparison with sym->st_size is missing.
> > 
> > This was intentional, as my understanding of the historical behavior
> > on other implementations was that it would do this. If that's
> > incorrect we should investigate and document (or find existing
> > documentation of) what they really do.
> I don't know how the historical behavior was. Maybe you could point me to 
> some resources.
> However, I found that st_size might be 0, if the symbol has no or an unknown
> size. How about comparing st_size to zero?
> 
> -                       if (symaddr > addr || symaddr < best)
> +                       if (symaddr > addr || ((sym->st_size != 0) && ((void*) ((uint8_t*) symaddr + sym->st_size) < addr)) || symaddr < best)

I think this should be <= not <. symaddr+sym->st_size is one past the
end of the object/function, not part of it.

Aside from that, a couple style issues. This line is very long (well
over 80) after the change, and in musl we generally don't use !=0 or
excessive parens. Changing those things would help the length too.
Should also be char * rather than uint8_t*. With these changes I think
it looks like:

			if (symaddr > addr || (sym->st_size && ((void*)((char *)symaddr + sym->st_size) < addr)) || symaddr < best)

which is still really long. We could eliminate all the cast mess by
changing the addresses all to uintptr_t, which really should be done
(as a separate patch) anyway, since relational operators on pointers
that don't point into the same arrays is UB. But it still leaves the
line well over 80 chars. If may be best to write it as:

			if (symaddr > addr || symaddr < best
			    || (sym->st_size && symaddr+sym->st_size < addr))
				continue;

or even (simple patch):

			if (symaddr > addr || symaddr < best)
				continue;
+ 			if (sym->st_size && symaddr+sym->st_size < addr)
+ 				continue;

I can handle the independent UB fix and reformatting if you like.

> > > @@ -1967,13 +1967,16 @@ int dladdr(const void *addr, Dl_info *info)
> > >                 }
> > >         }
> > >
> > > -       if (!best) return 0;
> > > -
> > > -       if (DL_FDPIC && (bestsym->st_info&0xf) == STT_FUNC)
> > > -               best = p->funcdescs + (bestsym - p->syms);
> > > -
> > >         info->dli_fname = p->name;
> > >         info->dli_fbase = p->map;
> > > +       if (!best) {
> > > +               info->dli_sname = 0;
> > > +               info->dli_saddr = 0;
> > > +               return 0
> > 
> > This is missing a ; so it seems you tested a slightly different patch..?
> Sorry, that's embarrassing. I slightly refactored after testing.
> This line should be:
> +                   return 1;

OK, that looks right.

Rich


  reply	other threads:[~2018-04-13  1:01 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-03 13:06 Siebenborn, Axel
2018-04-10  7:22 ` FW: " Siebenborn, Axel
     [not found] ` <20180410142312.GE3094@brightrain.aerifal.cx>
2018-04-11  8:07   ` Siebenborn, Axel
2018-04-13  1:01     ` Rich Felker [this message]
2018-04-13 10:16       ` Siebenborn, Axel
2018-05-16  8:16         ` Siebenborn, Axel
2018-05-16 23:16           ` Rich Felker
2018-05-17  2:06             ` William Pitcock
2018-06-27 20:02             ` Rich Felker
2018-06-28 15:51               ` 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=20180413010152.GS3094@brightrain.aerifal.cx \
    --to=dalias@libc.org \
    --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).