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=-4.9 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,NICE_REPLY_A,RCVD_IN_DNSWL_MED, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 29402 invoked from network); 14 Sep 2023 09:23:28 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 14 Sep 2023 09:23:28 -0000 Received: (qmail 9377 invoked by uid 550); 14 Sep 2023 09:23:23 -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 9336 invoked from network); 14 Sep 2023 09:23:22 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zhasha.com; s=wirbelwind; t=1694683388; bh=AxlsrwD/T923a5mGSMVjxyXR6CVawlnYTCMfL+uUURY=; h=Date:From:To:Subject:In-Reply-To:References; b=ZdHppq+wn2j48uMkbu0l3Ykhpg4dEhfFEAa1GyEq5q9HkK5bitFv9GrLrB3Ij/vmz 3HOFdAROTvDOW+Nvx8J8rtGfs1PtRpbl05dbEa2azipRmPzEatQM5TKnKWZPXxFmcL 5jLTg4bKHNL6eNFYL8sgA5Z99Z1sG8prW8jAfWB8= Date: Thu, 14 Sep 2023 11:23:08 +0200 From: Joakim Sindholt To: musl@lists.openwall.com Message-Id: <20230914112308.bc1833d3f827ada2d1b7d85c@zhasha.com> In-Reply-To: References: <20230908174939.80579-1-jamestiotio@gmail.com> <20230909004835.GD4163@brightrain.aerifal.cx> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: [musl] [PATCH] Add a safe dequeue integrity check for mallocng On Thu, 14 Sep 2023 13:13:23 +0800, James R T wrote: > On Sat, Sep 9, 2023 at 8:48 AM Rich Felker wrote: > > > > This could and should be written with the assert macro, like all the > > other safety assertions in mallocng, not pulling in stdio and abort. > > Understood. I was not able to find an assert with `predict_false` for > the condition. Should I add one assert function with `predict_false` > in `include/assert.h` or `src/exit/assert.c` or simply use the regular > assert? It's a little confusing but assert() in mallocng is not real assert(): http://git.musl-libc.org/cgit/musl/tree/src/malloc/mallocng/glue.h#n33 The issue is that if memory is under control of an attacker then doing anything at all, especially running the stdio machinery, is unsafe. To that end musl uses a_crash() here which expands to a minimal set of instructions to crash the process: http://git.musl-libc.org/cgit/musl/tree/arch/x86_64/atomic_arch.h#n106 Furthermore, musl doesn't use any of thosed tagged branch tricks and I personally doubt it would make any difference.