From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/9345 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: Wed, 17 Feb 2016 04:15:33 -0500 Message-ID: References: <20160216215550.GC9915@port70.net> <20160217090327.4c6b5790@vostro.util.wtbts.net> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a1141cff6382fd3052bf3b126 X-Trace: ger.gmane.org 1455700562 32091 80.91.229.3 (17 Feb 2016 09:16:02 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 17 Feb 2016 09:16:02 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-9358-gllmg-musl=m.gmane.org@lists.openwall.com Wed Feb 17 10:15:50 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 1aVyD7-0002Xq-BQ for gllmg-musl@m.gmane.org; Wed, 17 Feb 2016 10:15:49 +0100 Original-Received: (qmail 32629 invoked by uid 550); 17 Feb 2016 09:15:46 -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 32605 invoked from network); 17 Feb 2016 09:15:45 -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=+5nXNUk6tXSCSi6eeq8/1p/iQwmft/ol8RMgCa50hOE=; b=JvBIfPmJ6Z3wUkPIbenRaKjp935eLzoe/Aio7WhiJQ3K/OZ1iFl5begnATOdtbMbdL yPm7gzJ2dx/1QvR2kJXSy4LBnfxHV8enJxiLWAGAYWKTTMzUqKCaETxX4rLauBzjmSaW W88HQwnZru0gDTgLANddrilYg8wXcd0bbSyk12RVwdlaQrSfN5v4dx5m+fNoNjuUcQFj ATUlfvsR7sNH2biqi6E8elmRnlgU1KPEk0Ovgke4BmelVH8s2pltGyJzqW+6NarZlWOp 7HXsqxj6iBU+ttssJYsvvAMko5Vl/seRQBLMQocfMkiuTE1RvB8L8k8U0dMJqKtIgkwG UJBg== 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=+5nXNUk6tXSCSi6eeq8/1p/iQwmft/ol8RMgCa50hOE=; b=kShKSyUDLvZPpP+Rb4CLmeBlU1YoLT7aDF9IdsKCUqHCG8mM4kOljvujbC5v2q7jqx ohOWpowbbnyyD7lOmzOxWHl6Qju4gQ1Ev2uKZSL+/46s+xAop58l1X/W3zC8YJ69axhl mgbhkArkwYtGmkyclT8LFEzEmwbhaB5rkI+i+m6wJQC2CWznSX/d3Sf/4J+aC0cuSLpC a/4L3E+zznLfD3g9iJH0aB3H8htkIjIseKolWQJCuG6THGpL2rIhfUDIQGWOQ2WOQOtY I16NflmA0bYnHvUKJGm5vR8tFp+d+VhK96BCHvZFH8CAGvVdy6QpnhV6pzOgbP/d6rFd r88g== X-Gm-Message-State: AG10YOSCzgNHzkao0rv1SpzXx6W7O3kXEK/M5ocVGdgpMZhSxRSfscCnyA4ly/k/I9RYKETYbW5+GkUUoQOpn9+K X-Received: by 10.28.126.65 with SMTP id z62mr2447201wmc.3.1455700533838; Wed, 17 Feb 2016 01:15:33 -0800 (PST) In-Reply-To: <20160217090327.4c6b5790@vostro.util.wtbts.net> Xref: news.gmane.org gmane.linux.lib.musl.general:9345 Archived-At: --001a1141cff6382fd3052bf3b126 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Finally figured it out: 1. musl is reclaiming space from the executable starting at offset 0x224B20, i.e. at the end of the bss 2. this reclaimed space gets used for the dso struct of the first shared li= b 3. the last variable in the bss appears to be scratch space for checksum computation 4. the code is assuming "unsigned long" to be 4 bytes, which isn't the case on 64bit platforms 5. the checksum code overflows out of the bss, corrupting the dso struct 6. this issue is masked in a glibc environment because the loader doesn't make the unused part of the program pages available to malloc. 7. valgrind doesn't catch the problem because it doesn't bound-check global= s Sorry about the noise. =E2=80=8B --001a1141cff6382fd3052bf3b126 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Finally figured it out:

1. m= usl is reclaiming space from the executable starting at offset 0x224B20, i.= e. at the end of the bss
2. this reclaimed space gets used for th= e dso struct of the first shared lib
3. the last variable in the = bss appears to be scratch space for checksum computation
4. the c= ode is assuming "unsigned long" to be 4 bytes, which isn't th= e case on 64bit platforms
5. the checksum code overflows out of t= he bss, corrupting the dso struct
6. this issue is masked in a gl= ibc environment because the loader doesn't make the unused part of the = program pages available to malloc.
7. valgrind doesn't catch = the problem because it doesn't bound-check globals

=
Sorry about the noise.

=E2=80=8B
--001a1141cff6382fd3052bf3b126--