From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/2194 Path: news.gmane.org!not-for-mail From: Paul Schutte Newsgroups: gmane.linux.lib.musl.general Subject: Re: Possible file stream bug Date: Wed, 24 Oct 2012 23:22:13 +0200 Message-ID: References: <20121024205904.GJ254@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=e89a8ff246e11e25e804ccd4ae0d X-Trace: ger.gmane.org 1351113749 6114 80.91.229.3 (24 Oct 2012 21:22:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 24 Oct 2012 21:22:29 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-2195-gllmg-musl=m.gmane.org@lists.openwall.com Wed Oct 24 23:22:38 2012 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1TR8PJ-00065B-WC for gllmg-musl@plane.gmane.org; Wed, 24 Oct 2012 23:22:34 +0200 Original-Received: (qmail 3900 invoked by uid 550); 24 Oct 2012 21:22:26 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 3892 invoked from network); 24 Oct 2012 21:22:25 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=/oEQRqqbyx3hyuBwJau3JnCB+qRP8NcihkxvEKA7e+A=; b=LfoTW6J7U0o5U0TopsHOjpjBXcp+W6tZXZF8ikRB5IOcwYVaRHXpVUNCTddr3dEqKE hlnJMEmkmjsxtnnna+tVmvSSoZtyOAqcXbyoqIwaZiOTNOtpzm8+/X5tjTNYNzIbB1Eo QMfJg7fmPX/a4vUPeHRjd0BlNRbgeFcqGBjhc0Sq53lKR2Fq3oQ+QGLcrcCg+Fgzp7Ft VWsmVKRCUsF/4/7ymW2Jtz2fO19PWE26zOIvw0PmBOYYL26V08he8Wdn+0UhuMN+r0yV o6Gocfp2EcxlARfrEnXOIzXZZf7yH5ap+PjZmKJmzwo3Vjgr5OAuKDLDkhrqDYDMgDRb oDxw== In-Reply-To: <20121024205904.GJ254@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:2194 Archived-At: --e89a8ff246e11e25e804ccd4ae0d Content-Type: text/plain; charset=ISO-8859-1 Hi, It is not my code, but I can not see why it is invalid. Here is a strace when linked agains glibc: close(1) = 0 open("/dev/tty", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 1 fstat(1, {st_mode=S_IFCHR|0666, st_rdev=makedev(5, 0), ...}) = 0 ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f6eb782e000 write(1, "test this\n", 10) = 10 exit_group(0) = ? Here is an strace aganst musl: close(1) = 0 open("/dev/tty", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 1 ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0 dup2(1, 1) = 1 close(1) = 0 writev(1, [{"test this", 9}, {"\n", 1}], 2) = -1 EBADF (Bad file descriptor) exit_group(0) = ? Musl is doing a dup2 and then closes the old descriptor. In this case, it is the same and therefore the stream is closed. One could possibly test for the case where newfd==oldfd and not close oldfd in that case. Or am I missing something ? Regards Paul On Wed, Oct 24, 2012 at 10:59 PM, Rich Felker wrote: > On Wed, Oct 24, 2012 at 09:36:28PM +0200, Paul Schutte wrote: > > Hi > > > > I compiled and linked libwebserver-0.5.3 against musl. > > > > It would just strangely break halfway through a request. After hours of > > searching, I found the problem. > > > > I can demonstrate it with the following code: > > > > #include > > #include > > > > int main() { > > FILE *fstream; > > > > fclose(stdout); > > > > fstream=freopen("/dev/tty","w",stdout); > > > > if (fstream==NULL) { > > fprintf(stderr,"freopen failed\n"); > > } > > > > printf("test this\n"); > > > > > > return 0; > > } > > > > This snippet works fine when using glibc. > > This code is invalid; you have invoked undefined behavior by accessing > stdout (passing it to freopen) after it was closed with fclose. Remove > the fclose and it works correctly. This code would certainly cause > memory corruption and/or crash if it were used on any FILE other than > one of the 3 builtin ones (since the memory would have been returned > to the heap when fclose was called) so there is no sense in trying to > support this invalid usage. You should file a bug report with the > application. > > Rich > --e89a8ff246e11e25e804ccd4ae0d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

It is not my code, but I can not see why it is invalid.

H= ere is a strace when linked agains glibc:

close(1)=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =3D 0
open("/dev/tty", O_WRONLY|O_CREAT|O_TRUNC, 0666) =3D 1<= br> fstat(1, {st_mode=3DS_IFCHR|0666, st_rdev=3Dmakedev(5, 0), ...}) =3D 0
i= octl(1, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...})= =3D 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,= -1, 0) =3D 0x7f6eb782e000
write(1, "test this\n", 10)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = =3D 10
exit_group(0)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D ?

Here is an strace aganst musl:
=
close(1)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0
open("/dev/tty", O_WRONLY= |O_CREAT|O_TRUNC, 0666) =3D 1
ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}= ) =3D 0
dup2(1, 1)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 1
close(1)=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 0=
writev(1, [{"test this", 9}, {"\n", 1}], 2) =3D -1 = EBADF (Bad file descriptor)
exit_group(0)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0 =3D ?

Musl is doing a dup2 and then closes the ol= d descriptor. In this case, it is the same and therefore the stream is clos= ed.
One could possibly test for the case where newfd=3D=3Doldfd and not = close oldfd in that case. Or am I missing something ?

Regards
Paul

On Wed, Oct 24, 2012 = at 10:59 PM, Rich Felker <dalias@aerifal.cx> wrote:
On Wed, Oct 24, 2012 at 09:36:28PM +0200, Paul Schutte wrote:
> Hi
>
> I compiled and linked libwebserver-0.5.3 against musl.
>
> It would just strangely break halfway through a request. After hours o= f
> searching, I found the problem.
>
> I can demonstrate it with the following code:
>
> #include <unistd.h>
> #include <stdio.h>
>
> int main() {
> =A0 =A0 FILE *fstream;
>
> =A0 =A0 fclose(stdout);
>
> =A0 =A0 fstream=3Dfreopen("/dev/tty","w",stdout);<= br> >
> =A0 =A0 if (fstream=3D=3DNULL) {
> =A0 =A0 =A0 =A0 fprintf(stderr,"freopen failed\n");
> =A0 =A0 }
>
> =A0 =A0 printf("test this\n");
>
>
> =A0 =A0 return 0;
> }
>
> This snippet works fine when using glibc.

This code is invalid; you have invoked undefined behavior by accessing
stdout (passing it to freopen) after it was closed with fclose. Remove
the fclose and it works correctly. This code would certainly cause
memory corruption and/or crash if it were used on any FILE other than
one of the 3 builtin ones (since the memory would have been returned
to the heap when fclose was called) so there is no sense in trying to
support this invalid usage. You should file a bug report with the
application.

Rich

--e89a8ff246e11e25e804ccd4ae0d--