From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/9339 Path: news.gmane.org!not-for-mail From: Hugues Bruant Newsgroups: gmane.linux.lib.musl.general Subject: Re: dynlink.c: bug in reclaim_gaps leading to segfault in __libc_exit_fini Date: Tue, 16 Feb 2016 19:05:27 -0500 Message-ID: References: <20160216215550.GC9915@port70.net> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a1130ce1ce3b6d3052bec0177 X-Trace: ger.gmane.org 1455667546 10265 80.91.229.3 (17 Feb 2016 00:05:46 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 17 Feb 2016 00:05:46 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-9352-gllmg-musl=m.gmane.org@lists.openwall.com Wed Feb 17 01:05:42 2016 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1aVpcj-0000sm-Sc for gllmg-musl@m.gmane.org; Wed, 17 Feb 2016 01:05:42 +0100 Original-Received: (qmail 28355 invoked by uid 550); 17 Feb 2016 00:05:39 -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 28335 invoked from network); 17 Feb 2016 00:05:38 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aerofs-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=gF2DZWqDLOu/8g05NhPNpdlYiDYOIZ8aXANPbShVzao=; b=nyRxSx9tVRqVeDTjma5Ks88XyhDqCd/vftoJBAojQyMucqG2rzecNxyucAKqfePShD UYI734iFaZMxPNyv5a3zy1VgEOkkhwJ6aSjUrj88JF007YQqbGT1+AdR8a+yPekEd9f1 8sJWI7vAGaz6jDXC88U9zFQB29IuCNuTyfFO38Z5lfMKoNsXWqMRb2SBXs6aXPvX05l0 R7nlQar4q5Bw3Aa+1ATqENMj4pND5vU+pmKOB8g08RgH1aQKfl9HTQdZW0C+nIF3YVz2 4byNX4G/bNrurAj5AD+o4gRiTB1OG2nRkZvg4kl7gg1ZQGs3iL5U5Hug3b9KZ7S+2kxW nUyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=gF2DZWqDLOu/8g05NhPNpdlYiDYOIZ8aXANPbShVzao=; b=HLrIYp65G3HCgPP0vKijkzXpeFYZT0D4k9dW4q1RJhTBhzyd0BLDzhbPoeNLj+Jj8x rN22t/cQWAh9SYp371b/fwMNADdhijrcd8oRsppMo2Cq/oecYqtyhdTEVferew40HOrR UJLtSiyzwS1HAOtLZ79biyMfPgTNyhjeXvtzo6cNMGPHnXbqCPc+WL6Mbuvkf7G+FxdE /plUzz48pKI2VfruScA+70NuH/JKtyXQMshYpkMLEhVasLU2ZGVwmXFtUa/zAw2Nr2+W 52yVDO3uJQFfIKbViEPGwNmsrKo7HW+IbKIAR0Pphmkq+xSvn+8MDle5Ct0qTSpZA4gP b9yw== X-Gm-Message-State: AG10YOQbBu6qht91GvLC2gWUFomoRRpUaBeu1dv8HpUxpaQEVPl478xRGjBLsC/2Me4nv5MMjV+Z0qz+uBpxDRBR X-Received: by 10.194.113.38 with SMTP id iv6mr2184930wjb.126.1455667527522; Tue, 16 Feb 2016 16:05:27 -0800 (PST) In-Reply-To: <20160216215550.GC9915@port70.net> Xref: news.gmane.org gmane.linux.lib.musl.general:9339 Archived-At: --001a1130ce1ce3b6d3052bec0177 Content-Type: text/plain; charset=UTF-8 > > ==59== Invalid free() / delete / delete[] / realloc() > > ==59== at 0x4C92B0E: free (vg_replace_malloc.c:530) > > ==59== by 0x4056F68: reclaim_gaps (dynlink.c:488) > > ==59== by 0x405743D: map_library (dynlink.c:708) > > ==59== by 0x4057EF3: load_library (dynlink.c:1014) > > ==59== by 0x4058CA8: load_preload (dynlink.c:1112) > > ==59== by 0x4058CA8: __dls3 (dynlink.c:1581) > > ==59== by 0x405856A: __dls2 (dynlink.c:1383) > > ==59== by 0x405655E: ??? (in /lib/ld-musl-x86_64.so.1) > > ==59== by 0x3: ??? > > ==59== by 0xFFF000E3A: ??? > > ==59== by 0xFFF000E3E: ??? > > ==59== by 0xFFF000E44: ??? > > ==59== by 0xFFF000E86: ??? > > > > Afterwards, the program proceeds with no issue, until it exists, at which > > point a segfault is triggered when cleaning up shared libraries: > > > > this is not a bug. How confident of that are you? Something is reliably overwriting 32 bytes of a dso struct. Valgrind supposedly catches out-of-bounds writes to heap-allocated arrays so unless I'm mistaken, the absence of any other errors until the segfault suggests that there is no out-of-bounds write and the logical conclusion is that an allocation overlaps with the corrupted dso struct. The program is not using any threads so if I understand correctly it sohuld not be negatively affected by the small default stack size. In any case, I enabled -fstack-protector-all and -fstack-check and this did not reveal any issue so at this point I'm ruling out stack overflow as the source of the corruption. Quite frankly I'm hoping that the root cause is in libdmg-hfsplus because it would be much easier to fix than musl but the evidence does not point in that direction. Any suggestions for further investigation would be appreciated. --001a1130ce1ce3b6d3052bec0177 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

=
> =3D=3D59=3D=3D Invalid= free() / delete / delete[] / realloc()
> =3D=3D59=3D=3D=C2=A0 =C2=A0 at 0x4C92B0E: free (vg_replace_malloc.c:53= 0)
> =3D=3D59=3D=3D=C2=A0 =C2=A0 by 0x4056F68: reclaim_gaps (dynlink.c:488)=
> =3D=3D59=3D=3D=C2=A0 =C2=A0 by 0x405743D: map_library (dynlink.c:708)<= br> > =3D=3D59=3D=3D=C2=A0 =C2=A0 by 0x4057EF3: load_library (dynlink.c:1014= )
> =3D=3D59=3D=3D=C2=A0 =C2=A0 by 0x4058CA8: load_preload (dynlink.c:1112= )
> =3D=3D59=3D=3D=C2=A0 =C2=A0 by 0x4058CA8: __dls3 (dynlink.c:1581)
> =3D=3D59=3D=3D=C2=A0 =C2=A0 by 0x405856A: __dls2 (dynlink.c:1383)
> =3D=3D59=3D=3D=C2=A0 =C2=A0 by 0x405655E: ??? (in /lib/ld-musl-x86_64.= so.1)
> =3D=3D59=3D=3D=C2=A0 =C2=A0 by 0x3: ???
> =3D=3D59=3D=3D=C2=A0 =C2=A0 by 0xFFF000E3A: ???
> =3D=3D59=3D=3D=C2=A0 =C2=A0 by 0xFFF000E3E: ???
> =3D=3D59=3D=3D=C2=A0 =C2=A0 by 0xFFF000E44: ???
> =3D=3D59=3D=3D=C2=A0 =C2=A0 by 0xFFF000E86: ???
>
> Afterwards, the program proceeds with no issue, until it exists, at wh= ich
> point a segfault is triggered when cleaning up shared libraries:
>

this is not a bug.
How confident of that are you?

Something is reliably overwriting 32 bytes of a dso= struct. Valgrind
supposedly catches out-of-bounds writes to = heap-allocated arrays so
unless I'm mistaken, the absence of = any other errors until the segfault
suggests that there is no out= -of-bounds write and the logical conclusion
is that an allocation= overlaps with the corrupted dso struct.

The progr= am is not using any threads so if I understand correctly it sohuld
not be negatively affected by the small default stack size. In any case, = I
enabled -fstack-protector-all and -fstack-check and this did no= t reveal any
issue so at this point I'm ruling out stack over= flow as the source of the
corruption.

Qu= ite frankly I'm hoping that the root cause is in libdmg-hfsplus because=
it would be much easier to fix than musl but the evidence does n= ot point
in that direction.

Any suggesti= ons for further investigation would be appreciated.
--001a1130ce1ce3b6d3052bec0177--