From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_MSPIKE_H2 autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 16204 invoked from network); 24 Feb 2023 14:42:27 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 24 Feb 2023 14:42:27 -0000 Received: (qmail 7215 invoked by uid 550); 24 Feb 2023 14:42:24 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 7174 invoked from network); 24 Feb 2023 14:42:23 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=URFwb9nkgMMQ5qvQBwPbB2HnD+P+/b2wQsurv0XtpQU=; b=JP+rCIKwZmbQZe7bnVYT4kz1futy2efKbpQuikWZGANidMPdL58AgAdo9tJ/WTtt2G fiNzoKV/tix4zhbeYau/eIDiXMu5ciH7H1akxVsrMEBltR2tWzmlLlQqbqEWC/QOSs32 K4vZlS6EjYLTzIun/QAHdVpcwSsumL4OtBhLOfdLLvtEFmr0MiinDhDaZhx5Yf/z8ZE4 ZB+vTzHgMgidtgdzG5K1FyWR57/2ewNW9tDK4McXBulI0WpT4c4Pf2KKzIP6a/WLzr5m NHYDaLsCMxGgSjU0kfQ7SDl05gX/I8ZerPmOYN/oXOc0x51zd4k4I2fY4Zl2OP7X9/Di UxBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=URFwb9nkgMMQ5qvQBwPbB2HnD+P+/b2wQsurv0XtpQU=; b=8NieljRzBFp/qu7U4qYCFW2Jv8GI6AF4hQH6Cssxl8y4E9LRTaV0jb1AJybzFuTcBr F3pZD8DNuu4HgakWL7nrzBbYNLglJ5LFtasj1ibFxDOziTgpz7UXNyPCbnoikoXUiBRX tqmkyhWaQORIYSJBetcc1te8BRLHiRyXNsPiZar93WGwoSOQwqgOL7iCHORnVn1Rnzsu fZavTICsAjBsZ1pHdqSpHcspRIW2iJ81PCplMsDtgOY7nxJi40TVW3FYgKRvyrAkbyu9 ycC/Tg7t2sA3Ps1zsbHtN5KHx6dxKdODol7ZcAqdGm4OLiY/rVYOM5SLegr1T+6XZCNb fQKw== X-Gm-Message-State: AO0yUKWZATYGkLP1sU3nOXtIcFPtbZ2ViZI6RZkErdwLws6dc5Yow7Jw THreDVC7uMLRtddiz2+EPHj7rRVifvj9xWDZlYo0 X-Google-Smtp-Source: AK7set8YAqcUsoDpdA7wNfZh5kwBdZuZEOsEqVp2p94hKjnFk3aLrZ/grDLGWA/IE0l5cDrYiMXyUTwXuh8Cdzcww7c= X-Received: by 2002:a05:690c:f92:b0:533:a15a:d33e with SMTP id df18-20020a05690c0f9200b00533a15ad33emr6232880ywb.5.1677249731669; Fri, 24 Feb 2023 06:42:11 -0800 (PST) MIME-Version: 1.0 References: <20230224133413.GE4163@brightrain.aerifal.cx> <20230224135511.iunglqtcvpjeqgtv@gen2.localdomain> <20230224140739.GF4163@brightrain.aerifal.cx> <20230224141731.dm4w7fbfkczbx42e@gen2.localdomain> In-Reply-To: <20230224141731.dm4w7fbfkczbx42e@gen2.localdomain> From: Tamir Duberstein Date: Fri, 24 Feb 2023 09:42:00 -0500 Message-ID: To: NRK Cc: Rich Felker , musl@lists.openwall.com Content-Type: multipart/alternative; boundary="000000000000754faa05f57322b5" Subject: Re: [musl] undefined behavior in fread.c --000000000000754faa05f57322b5 Content-Type: text/plain; charset="UTF-8" We could take the lock and still avoid UB with an early return. On Fri, Feb 24, 2023, 09:17 NRK wrote: > On Fri, Feb 24, 2023 at 09:07:41AM -0500, Rich Felker wrote: > > stdio functions are required (by POSIX) to behave as if they take a > > mutex on the FILE. If fread with a length of zero makes forward > > progress when another thread holds the lock, this is non-conforming. > > OK, I see. Wasn't aware of that. > > On a sidenote, if I'm reading the right function (libio/iofread.c) then > glibc is taking the lock _after_ they do the size check. > > if (bytes_requested == 0) > return 0; > _IO_acquire_lock (fp); > /* ... */ > > - NRK > --000000000000754faa05f57322b5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
We could take the lock and still avoid UB with an early r= eturn.

On Fri, Feb 24, 2023, 09:17 NRK <nrk@disroot.org> wrote:
On= Fri, Feb 24, 2023 at 09:07:41AM -0500, Rich Felker wrote:
> stdio functions are required (by POSIX) to behave as if they take a > mutex on the FILE. If fread with a length of zero makes forward
> progress when another thread holds the lock, this is non-conforming.
OK, I see. Wasn't aware of that.

On a sidenote, if I'm reading the right function (libio/iofread.c) then=
glibc is taking the lock _after_ they do the size check.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if (bytes_requested =3D=3D 0)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return 0;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 _IO_acquire_lock (fp);
=C2=A0 =C2=A0 =C2=A0 =C2=A0 /* ... */

- NRK
--000000000000754faa05f57322b5--