From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id DDC83C6FD1D for ; Wed, 5 Apr 2023 00:51:50 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235839AbjDEAvu (ORCPT ); Tue, 4 Apr 2023 20:51:50 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36096 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235822AbjDEAvt (ORCPT ); Tue, 4 Apr 2023 20:51:49 -0400 Received: from smtp.gentoo.org (woodpecker.gentoo.org [140.211.166.183]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5279C10CF for ; Tue, 4 Apr 2023 17:51:48 -0700 (PDT) References: User-agent: mu4e 1.10.1; emacs 29.0.60 From: Sam James To: Siddhesh Poyarekar Cc: Mingye Wang , Alejandro Colomar , linux-man@vger.kernel.org, GNU C Library , DJ Delorie Subject: Re: [RFC PATCH] malloc_usable_size.3: Warn about _FORTIFY_SOURCE interaction Date: Wed, 05 Apr 2023 01:51:10 +0100 In-reply-to: Message-ID: <87lej7qhgu.fsf@gentoo.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Precedence: bulk List-ID: X-Mailing-List: linux-man@vger.kernel.org --=-=-= Content-Type: text/plain Siddhesh Poyarekar writes: > On 2023-04-04 01:52, Mingye Wang wrote: >> Hi all, >> In (somewhat) recent discussions about _FORTIFY_SOURCE level 3, a >> common snag to hit seems to be abuse of malloc_usable_size(). The >> attached patch is my attempt at making the situation easier to sort >> through. >> See siddhesh's comment on GitHub.[0] I wonder if the language needs >> to >> be stronger. >> [0]: https://github.com/systemd/systemd/issues/22801#issuecomment-1343041481 > > For more context of my statement, please see this discussion: > > https://sourceware.org/pipermail/libc-alpha/2022-November/143599.html > > which continued into the next month: > > https://sourceware.org/pipermail/libc-alpha/2022-December/143667.html > > This amendment that DJ wrote is probably the most precise description > of the current malloc_usage_size situation: > > The value returned by malloc_usable_size() may be greater than the > requested size of the allocation because of various internal > implementation details, none of which the programmer should rely on. > This function is intended to only be used for diagnostics and > statistics; writing to the excess memory without first calling > realloc() to resize the allocation is not supported. The returned > value is only valid at the time of the call; any other call to a > malloc family API may invalidate it. Honestly, I thought we'd committed that. Oops. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iOUEARYKAI0WIQQlpruI3Zt2TGtVQcJzhAn1IN+RkAUCZCzGEV8UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0MjVB NkJCODhERDlCNzY0QzZCNTU0MUMyNzM4NDA5RjUyMERGOTE5MA8cc2FtQGdlbnRv by5vcmcACgkQc4QJ9SDfkZAwDAD+O/TGZi4l3m6m8kR3FYlGv4M0goUjYH9Xsdqa B5uOgoAA/2I5RjMgC8gbUPgTs0m43wathXbPR3ucrhwv+E7jTZoJ =Wb07 -----END PGP SIGNATURE----- --=-=-=--