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.9 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_MSPIKE_H2,URIBL_BLACK autolearn=no autolearn_force=no version=3.4.4 Received: (qmail 3176 invoked from network); 24 Feb 2023 12:52:40 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 24 Feb 2023 12:52:40 -0000 Received: (qmail 30481 invoked by uid 550); 24 Feb 2023 12:52:35 -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 30438 invoked from network); 24 Feb 2023 12:52:34 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=UQs+lgmsa57R92VXVKt+aN8zG9tNxVa3ONlRFT6gJxA=; b=B+xAmqIRH8ALwe8xNwdnZVh8kiK500rr+UmS50u2p2lHMbd+r5wwOBsTU7LtTYcOua gyz8dlIVR5o+e6RCvrvUG2hCh2Wuv4EncumSyyG+zZC4+1rS2JbIeRA4Gq6YUbu4kQ2D tkAIf3UCtk1OnFRjwKx07fAm8losTg5ezmMoztT0mHgS5ZJY6LFC/lRgGNb9+QxKUcj9 Q7xoZdOk8sKGBTcRXMjERZhn7NrUEQDDorOygwjj60NU3GXfNC2c/sEwoEivVMqEzr6x zPVG58ReH3iXJ1+gq8+Ol21r+ior4AxmCF6TjUg+ghMn6SFPTy13pfVwKFfMLckwEI2/ fO1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=UQs+lgmsa57R92VXVKt+aN8zG9tNxVa3ONlRFT6gJxA=; b=jdYNmPbcQoOZabTt94SCKFwqGbJ+Ijl+GiQ8nJJQpcWivyaf1GAr4BeLoY7YmpYp9S vDp2FrRxfhnc7Mqq40H1Ux9MMiTEMa16+IrejLf0NdnToWdEoDbK6WXE/Q3RCp4tmnTs N+sHTZXzANF2pF1fSVVZFFq63949GLayQ2hhUuprnYCHDWA044F9mFQ4UZZMfC1UlSxE p7JnkDdZQFNqGxbI6qU96HJkMBAKgNu7zULphZeFC4ZAqD5W1hdYXZl0uD3zmDoYpr2h 5+Z7dfoTPrmcTftGbj6EDW4ssi2L3tCAyx4ZwhJN3wB+8xIu+2Vri4+oNwqYaoWIS1OW UO8Q== X-Gm-Message-State: AO0yUKXA+PnhA2G/nK+VXTTwCxgnRf99PZknt0/zpcZFHuXLklMO7U0g djiVwEbWSf+60I1ZzqkYlyKMuIHB3RPfRJzMPnHfjExhDzJ/7cMVPg== X-Google-Smtp-Source: AK7set9Q/BlECe8z7I5PuA6Y4xRdOyNNkc+FcOH359CtuRPyWT0EZgLWgmz0jZ3q9DROCW05wCbFB0kEz6piKnx25aE= X-Received: by 2002:a81:4509:0:b0:52e:ee55:a81e with SMTP id s9-20020a814509000000b0052eee55a81emr4456285ywa.7.1677243142276; Fri, 24 Feb 2023 04:52:22 -0800 (PST) MIME-Version: 1.0 From: Tamir Duberstein Date: Fri, 24 Feb 2023 07:52:11 -0500 Message-ID: To: musl@lists.openwall.com Content-Type: multipart/alternative; boundary="000000000000b36b6505f571999e" Subject: [musl] undefined behavior in fread.c --000000000000b36b6505f571999e Content-Type: text/plain; charset="UTF-8" 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 +0x168a6c #1.2 0x0000421373b5f4ec in ubsan_GetStackTrace() compiler-rt/lib/ubsan/ubsan_diag.cpp:41 +0x3d4ec #1.1 0x0000421373b5f4ec in MaybePrintStackTrace() compiler-rt/lib/ubsan/ubsan_diag.cpp:51 +0x3d4ec #1 0x0000421373b5f4ec in ~ScopedReport() compiler-rt/lib/ubsan/ubsan_diag.cpp:387 +0x3d4ec #2 0x0000421373b62684 in handlePointerOverflowImpl() compiler-rt/lib/ubsan/ubsan_handlers.cpp:809 +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 +0x168a6c #5 0x00004347972c0934 in FT_Stream_Seek(FT_Stream, FT_ULong) ../../third_party/freetype2/src/base/ftstream.c:64 +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. Thank you. Tamir --000000000000b36b6505f571999e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello, it's me again! I previously reported undefined = behavior in getdelim.c in=C2=A0https://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=C2= =A0https://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 po= inter (even by zero) is UB. Here's the stack trace:

../../zircon/third_party/ulib/musl/src/stdio/fread.c:22:10: runtime e= rror: applying zero offset to null pointer
=C2=A0 #0 =C2=A0 =C2=A00x0000= 8037bf602a6c in fread(void* restrict, size_t, size_t, FILE* restrict) ../..= /zircon/third_party/ulib/musl/src/stdio/fread.c:22 <libr.so>+0x168a6c=
=C2=A0 #1.2 =C2=A00x0000421373b5f4ec in ubsan_GetStackTrace() compiler-= rt/lib/ubsan/ubsan_diag.cpp:41 <l= ibclang_rt.asan.so>+0x3d4ec
=C2=A0 #1.1 =C2=A00x0000421373b5f4ec = in MaybePrintStackTrace() compiler-rt/lib/ubsan/ubsan_diag.cpp:51 <libclang_rt.asan.so>+0x3d4ec
= =C2=A0 #1 =C2=A0 =C2=A00x0000421373b5f4ec in ~ScopedReport() compiler-rt/li= b/ubsan/ubsan_diag.cpp:387 <libcl= ang_rt.asan.so>+0x3d4ec
=C2=A0 #2 =C2=A0 =C2=A00x0000421373b62684= in handlePointerOverflowImpl() compiler-rt/lib/ubsan/ubsan_handlers.cpp:80= 9 <libclang_rt.asan.so>+0x= 40684
=C2=A0 #3 =C2=A0 =C2=A00x0000421373b6239c in compiler-rt/lib/ubsan= /ubsan_handlers.cpp:815 <libclang= _rt.asan.so>+0x4039c
=C2=A0 #4 =C2=A0 =C2=A00x00008037bf602a6c in= fread(void* restrict, size_t, size_t, FILE* restrict) ../../zircon/third_p= arty/ulib/musl/src/stdio/fread.c:22 <libc.so>+0x168a6c
=C2=A0 #5 = =C2=A0 =C2=A00x00004347972c0934 in FT_Stream_Seek(FT_Stream, FT_ULong) ../.= ./third_party/freetype2/src/base/ftstream.c:64 <libfreetype2.so>+0xf1= 934

I think instead of `nmemb =3D 0` on line 1= 0 that should just return.

I've confirmed glib= c does a similar check and avoids UB in this case. See https://sourceware.org/git/?p=3Dglibc.git;a=3Dblob;f=3Dlibio/iofread.c;hb= =3DHEAD#l35 and=C2=A0https:= //godbolt.org/z/cYc9rG1ea.

Please CC me on res= ponses as I am not a subscriber to this mailing list
per the guidance on= https://musl.libc.org/suppo= rt.html.

Thank you.
Tamir
--000000000000b36b6505f571999e--