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.7 required=5.0 tests=MAILING_LIST_MULTI,
	RCVD_IN_MSPIKE_H2,URIBL_BLACK autolearn=no autolearn_force=no
	version=3.4.4
Received: (qmail 8473 invoked from network); 24 Feb 2023 13:34:30 -0000
Received: from second.openwall.net (193.110.157.125)
  by inbox.vuxu.org with ESMTPUTF8; 24 Feb 2023 13:34:30 -0000
Received: (qmail 5739 invoked by uid 550); 24 Feb 2023 13:34:27 -0000
Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm
Precedence: bulk
List-Post: <mailto:musl@lists.openwall.com>
List-Help: <mailto:musl-help@lists.openwall.com>
List-Unsubscribe: <mailto:musl-unsubscribe@lists.openwall.com>
List-Subscribe: <mailto:musl-subscribe@lists.openwall.com>
List-ID: <musl.lists.openwall.com>
Reply-To: musl@lists.openwall.com
Received: (qmail 5707 invoked from network); 24 Feb 2023 13:34:27 -0000
Date: Fri, 24 Feb 2023 08:34:14 -0500
From: Rich Felker <dalias@libc.org>
To: Tamir Duberstein <tamird@google.com>
Cc: musl@lists.openwall.com
Message-ID: <20230224133413.GE4163@brightrain.aerifal.cx>
References: <CAK-_uh7=5Ea3pESgEiDjWHifpe+x3w3-ccpDupz6d9ksyGqXLA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAK-_uh7=5Ea3pESgEiDjWHifpe+x3w3-ccpDupz6d9ksyGqXLA@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: Re: [musl] undefined behavior in fread.c

On Fri, Feb 24, 2023 at 07:52:11AM -0500, Tamir Duberstein wrote:
> Hello, it's me again! I previously reported undefined behavior in
> getdelim.c in https://www.openwall.com/lists/musl/2021/08/30/1, and just
> noticed this week that it has been fixed. Thank you!
> 
> After pulling in the latest changes, we now trip over UB in fread.c at
> https://git.musl-libc.org/cgit/musl/tree/src/stdio/fread.c#n21 on a
> `fread(NULL, 1, 0, ...)` call. `dest` is `NULL`, and incrementing a null
> pointer (even by zero) is UB. Here's the stack trace:
> 
> .../../zircon/third_party/ulib/musl/src/stdio/fread.c:22:10: runtime error:
> applying zero offset to null pointer
>   #0    0x00008037bf602a6c in fread(void* restrict, size_t, size_t, FILE*
> restrict) ../../zircon/third_party/ulib/musl/src/stdio/fread.c:22
> <libr.so>+0x168a6c
>   #1.2  0x0000421373b5f4ec in ubsan_GetStackTrace()
> compiler-rt/lib/ubsan/ubsan_diag.cpp:41 <libclang_rt.asan.so>+0x3d4ec
>   #1.1  0x0000421373b5f4ec in MaybePrintStackTrace()
> compiler-rt/lib/ubsan/ubsan_diag.cpp:51 <libclang_rt.asan.so>+0x3d4ec
>   #1    0x0000421373b5f4ec in ~ScopedReport()
> compiler-rt/lib/ubsan/ubsan_diag.cpp:387 <libclang_rt.asan.so>+0x3d4ec
>   #2    0x0000421373b62684 in handlePointerOverflowImpl()
> compiler-rt/lib/ubsan/ubsan_handlers.cpp:809 <libclang_rt.asan.so>+0x40684
>   #3    0x0000421373b6239c in compiler-rt/lib/ubsan/ubsan_handlers.cpp:815 <
> libclang_rt.asan.so>+0x4039c
>   #4    0x00008037bf602a6c in fread(void* restrict, size_t, size_t, FILE*
> restrict) ../../zircon/third_party/ulib/musl/src/stdio/fread.c:22
> <libc.so>+0x168a6c
>   #5    0x00004347972c0934 in FT_Stream_Seek(FT_Stream, FT_ULong)
> .../../third_party/freetype2/src/base/ftstream.c:64 <libfreetype2.so>+0xf1934
> 
> I think instead of `nmemb = 0` on line 10 that should just return.
> 
> I've confirmed glibc does a similar check and avoids UB in this case. See
> https://sourceware.org/git/?p=glibc.git;a=blob;f=libio/iofread.c;hb=HEAD#l35
> and https://godbolt.org/z/cYc9rG1ea.
> 
> Please CC me on responses as I am not a subscriber to this mailing list
> per the guidance on https://musl.libc.org/support.html.

Is there any indication that passing NULL as the first argument to
fread is not itself undefined? Normally I would expect that to be the
case.

Rich