From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS3215 2.6.0.0/16 X-Spam-Status: No, score=-4.2 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [IPv6:2620:52:3:1:0:246e:9693:128c]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 5821F1F601 for ; Fri, 2 Dec 2022 12:55:03 +0000 (UTC) Authentication-Results: dcvr.yhbt.net; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.b="i7xGhr7w"; dkim-atps=neutral Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 421643858C62 for ; Fri, 2 Dec 2022 12:55:02 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 421643858C62 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1669985702; bh=M50RWSx7EzP75xfq7UYN4viTX4IYlMXntAuTOGbZ/Lw=; h=To:Cc:Subject:References:Date:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=i7xGhr7wKBwq5ixQwbE/KpQRiurYFn+pYo9Vctulv0yLmrcSUIdD3NZgW6/UOuAmx I5iQs+Fj4mY0QL/oglEBFkiI0GOz9eleVabXEllL6ncAhgm55SCUkwub0/fxXxYY1W lZWOUdcWwqUX2dEg86tPTM+EStvj/9/TmpSvhje4= Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id CC0303858D28 for ; Fri, 2 Dec 2022 12:54:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org CC0303858D28 Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-217-zmUa0epnMLONxohvGZm4Hw-1; Fri, 02 Dec 2022 07:54:39 -0500 X-MC-Unique: zmUa0epnMLONxohvGZm4Hw-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 12A03811E75; Fri, 2 Dec 2022 12:54:39 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.2.16.87]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 14741200B416; Fri, 2 Dec 2022 12:54:37 +0000 (UTC) To: Siddhesh Poyarekar Cc: Andreas Schwab , libc-alpha@sourceware.org, carlos@redhat.com Subject: Re: [RFC] Supporting malloc_usable_size References: <20221124213258.305192-1-siddhesh@gotplt.org> <87sfhyrp19.fsf@igel.home> Date: Fri, 02 Dec 2022 13:54:34 +0100 In-Reply-To: (Siddhesh Poyarekar's message of "Fri, 2 Dec 2022 07:22:17 -0500") Message-ID: <87lenqrmnp.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.1 on 10.11.54.4 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Florian Weimer via Libc-alpha Reply-To: Florian Weimer Errors-To: libc-alpha-bounces+e=80x24.org@sourceware.org Sender: "Libc-alpha" * Siddhesh Poyarekar: > On 2022-12-02 07:03, Andreas Schwab wrote: >> On Nov 24 2022, Siddhesh Poyarekar wrote: >> >>> This is in context of this systemd issue: >>> >>> https://github.com/systemd/systemd/issues/22801 >>> >>> through which I had discovered that systemd was (ab)using >>> malloc_usable_size to use spare space in an allocated object. This was >>> discovered when _FORTIFY_SOURCE=3 flagged this as a buffer overflow, >>> since the compiler is unable to see that the space beyond the allocation >>> was safe to use. >> Which it isn't. Nothing prevents malloc to hand out the extra space >> to >> a different thread any time, so the size returned by malloc_usable_size >> can get outdated instantly. > > Not with the current malloc implementation I suppose but I get what > you mean. Florian had mentioned a similar caveat where a malloc > implementation could coalesce adjacent free blocks with the end of an > allocated block and change the value of malloc_usable_size at any > arbitrary point in time too. > > However the man page starts with "Although the excess bytes can be > overwritten by the application without ill effects" and maybe that > reassurance needs to be dropped. I think that is part of the interface contract. During the life-time of an allocation, the observed return value can only ever grow, never shrink. That's how I read the interface description (because it doesn't say the value is constant). However, systemd has cases which seem incompatible even with that: The code derives an array length from the malloc_usable_size return value. It assumes that if it has initialized the array up to that length at one point, all array elements are initialized. But when the array length is recomputed, new uninitialized elements may appear, so that's not really correct. Thanks, Florian