From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/12825 Path: news.gmane.org!.POSTED!not-for-mail From: "Siebenborn, Axel" Newsgroups: gmane.linux.lib.musl.general Subject: RE: [PATCH] dl_addr: compare addr with sym->st_size. Date: Wed, 16 May 2018 08:16:57 +0000 Message-ID: <3e3e78b2fbbb49c2952434473756b994@sap.com> References: <6a42ca4b6c9b4ea08925e232d7b57667@sap.com> <20180410142312.GE3094@brightrain.aerifal.cx> <20180413010152.GS3094@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1526458507 30196 195.159.176.226 (16 May 2018 08:15:07 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 16 May 2018 08:15:07 +0000 (UTC) To: "musl@lists.openwall.com" Original-X-From: musl-return-12841-gllmg-musl=m.gmane.org@lists.openwall.com Wed May 16 10:15:03 2018 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1fIraQ-0007lF-U6 for gllmg-musl@m.gmane.org; Wed, 16 May 2018 10:15:03 +0200 Original-Received: (qmail 10108 invoked by uid 550); 16 May 2018 08:17:10 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 10083 invoked from network); 16 May 2018 08:17:09 -0000 Thread-Topic: [musl] [PATCH] dl_addr: compare addr with sym->st_size. Thread-Index: AdPLTEBvr5Sbu89kTKWUonO61LEwTwFenFuAACg772AAUqdAAAAXbOFwBnbpZCA= In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.23.236] Xref: news.gmane.org gmane.linux.lib.musl.general:12825 Archived-At: Hi Rich, I wonder, when this patch will make it into the repository and when there i= s a released version with that patch. I'm not familiar with the release strategy of musl. I'm not sure if I misunderstood something and I have to do something in ord= er to get this patch in. Thanks, Axel=20 > -----Original Message----- > From: Siebenborn, Axel [mailto:axel.siebenborn@sap.com] > Sent: Freitag, 13. April 2018 12:17 > To: musl@lists.openwall.com > Subject: [CAUTION] RE: [musl] [PATCH] dl_addr: compare addr with sym- > >st_size. >=20 > > -----Original Message----- > > From: Rich Felker [mailto:dalias@aerifal.cx] On Behalf Of Rich Felker > > 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 Felk= er > > > > 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 behavio= r > > > > 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 m= e > 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 !=3D 0) = && ((void*) > > ((uint8_t*) symaddr + sym->st_size) < addr)) || symaddr < best) > > > > I think this should be <=3D 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 !=3D0 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. >=20 > Thanks, that would be nice! >=20 > > > > > > > @@ -1967,13 +1967,16 @@ int dladdr(const void *addr, Dl_info *inf= o) > > > > > } > > > > > } > > > > > > > > > > - if (!best) return 0; > > > > > - > > > > > - if (DL_FDPIC && (bestsym->st_info&0xf) =3D=3D STT_FUNC) > > > > > - best =3D p->funcdescs + (bestsym - p->syms); > > > > > - > > > > > info->dli_fname =3D p->name; > > > > > info->dli_fbase =3D p->map; > > > > > + if (!best) { > > > > > + info->dli_sname =3D 0; > > > > > + info->dli_saddr =3D 0; > > > > > + return 0 > > > > > > > > This is missing a ; so it seems you tested a slightly different pat= ch..? > > > Sorry, that's embarrassing. I slightly refactored after testing. > > > This line should be: > > > + return 1; > > > > OK, that looks right. > > > > Rich > Thanks for looking at this and for considering the patch! > Axel