From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ot1-x333.google.com (mail-ot1-x333.google.com [IPv6:2607:f8b0:4864:20::333]) by sourceware.org (Postfix) with ESMTPS id C9B2E3858D1E for ; Wed, 29 Mar 2023 13:54:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org C9B2E3858D1E Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linaro.org Received: by mail-ot1-x333.google.com with SMTP id x8-20020a9d3788000000b0069f922cd5ceso8234540otb.12 for ; Wed, 29 Mar 2023 06:54:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1680098079; h=content-transfer-encoding:in-reply-to:organization:from:references :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=m64LFL34u+LOQ0Q3pFyf7ubPv4vyPK+QOYs6IlBAnTY=; b=M7e7DtMY3vdilvpdiVZfOp2CEyi4TmIQCjQhNhHsWvR9eI+xXCkXf0aBXaAKdhifxG +tSDwuqGT1c/cDUogG/A0B6pxXQALy7NpDyMx5Bm2S/HKrVpK3bg7pTBnjdhXypxKbrc apRObkSMXAMdSMb6STvb1Ys5CB9HmpCc3dzaB9lqDqwKwGmIEM+mqeNPwADuztLjBTBe kyWjPiVRq6b5bgC6ucIls7+Fv4YrCnXbRcaCV4Is1twQipyndLJ6xHonN+MvUXL10PGf Nm6PGy+rJRCczZI5743t0MubCiY9jo9XjOuUTSsuJXP+R3sV1RZSpaOlBLHMX0aKCPwl MjVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680098079; h=content-transfer-encoding:in-reply-to:organization:from:references :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=m64LFL34u+LOQ0Q3pFyf7ubPv4vyPK+QOYs6IlBAnTY=; b=f4er1rvsd81UHI2j8XahL4EqOn78RqVFtOJ4c8kiycyZgMkJrBD83/z+dptsoK0xh9 77fwbhC/VoEZL+dKBvGWp6lTYEqpOpVHLFhdJDdOw0MTC9bgL+toew4F+vize7P1TYsO NgK4ARF6zaRUb662U9cJOmErgU+oGCRA5uELRFzIUt71OnmdWCHBneG4Ah6rRpFGExIG A70h0PrcYQ825Cbl61xZSona9ygT1HPOuz5PV+uT7rNmDc79kwmif4/wSXOlwJUmK84a yXzv281eids69LUYDCy3J0WSSrHZXee3dCDWZrlTRK0/kgZPVtkYQjQbrrlcGlFKbTNk qhHQ== X-Gm-Message-State: AAQBX9fprk/PETS7yszCMCDR2Q+OH3916oaKdA19g5+Z+f7yUgFxAMRT y3BFAlLXfMMDlLucwl08ddpJ3g== X-Google-Smtp-Source: AKy350ZEjyYm2TmYD10DN2BcL26bIzDGASid6HRx5RaqJgnFH7mPCE6T2hnS1HHemLLt0Gtg0XCn3Q== X-Received: by 2002:a9d:7312:0:b0:6a1:2c80:5a3f with SMTP id e18-20020a9d7312000000b006a12c805a3fmr962154otk.19.1680098079031; Wed, 29 Mar 2023 06:54:39 -0700 (PDT) Received: from ?IPV6:2804:1b3:a7c1:60f9:1426:1d2d:d6b:1761? ([2804:1b3:a7c1:60f9:1426:1d2d:d6b:1761]) by smtp.gmail.com with ESMTPSA id z2-20020a05683010c200b006a05475d931sm6194797oto.53.2023.03.29.06.54.37 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 29 Mar 2023 06:54:38 -0700 (PDT) Message-ID: <1da89fa5-e322-7cfa-0e0c-7074a4436a44@linaro.org> Date: Wed, 29 Mar 2023 10:54:36 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.9.0 Subject: Re: [PATCH 01/13] elf: strdup() l_name if no realname [BZ #30100] Content-Language: en-US To: Stas Sergeev , libc-alpha@sourceware.org References: <20230318165110.3672749-1-stsp2@yandex.ru> <20230318165110.3672749-2-stsp2@yandex.ru> From: Adhemerval Zanella Netto Organization: Linaro In-Reply-To: <20230318165110.3672749-2-stsp2@yandex.ru> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-12.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 18/03/23 13:50, Stas Sergeev via Libc-alpha wrote: > _dl_close_worker() has this code: > /* This name always is allocated. */ > free (imap->l_name); > > But in that particular case, while indeed being allocated, l_name > doesn't point to the start of an allocation: > new = (struct link_map *) calloc (sizeof (*new) + audit_space > + sizeof (struct link_map *) > + sizeof (*newname) + libname_len, 1); > ... > new->l_symbolic_searchlist.r_list = (struct link_map **) ((char *) (new + 1) > + audit_space); > > new->l_libname = newname > = (struct libname_list *) (new->l_symbolic_searchlist.r_list + 1); > newname->name = (char *) memcpy (newname + 1, libname, libname_len); > ... > new->l_name = (char *) newname->name + libname_len - 1; > > It therefore cannot be freed separately. > Use strdup("") as a simple fix. This is not required, the l_name alias to newname->name is only used for __RTLD_OPENEXEC (used by loader on DT_NEEDED) and these handlers are not meant to be dlclose. So even if the programs get an already opened handler to a DT_NEEDED object: void *h = dlopen ("libc.so.6", RTLD_NOW); assert (h != NULL); dlclose (h); The _dl_close_worker comment is indeed correct: the l_name for dlopen is *always* allocated by open_path so it can always call free on it. > > Signed-off-by: Stas Sergeev > --- > elf/dl-object.c | 5 ++++- > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/elf/dl-object.c b/elf/dl-object.c > index f1f2ec956c..ab926cd4bf 100644 > --- a/elf/dl-object.c > +++ b/elf/dl-object.c > @@ -122,7 +122,10 @@ _dl_new_object (char *realname, const char *libname, int type, > #endif > new->l_name = realname; > else > - new->l_name = (char *) newname->name + libname_len - 1; > + /* When realname="", it is not allocated and points to the constant > + string. Constness is dropped by an explicit cast. :( > + So strdup() it here. */ > + new->l_name = __strdup (""); > > new->l_type = type; > /* If we set the bit now since we know it is never used we avoid