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: AS17314 8.43.84.0/22 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,NICE_REPLY_A, 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 [8.43.85.97]) (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 0E5681F8C6 for ; Thu, 15 Jul 2021 13:51:27 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 08984385E829 for ; Thu, 15 Jul 2021 13:51:26 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 08984385E829 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1626357086; bh=XGs1852CF/72kdT4chja8zsZAi8rDlHwEgavpInUohw=; h=Subject:To:References:Date:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=xkbQo/st0G89IYIWcixxAxNwliP1US5OoIzUeoHyiAVENU9Tqb99z0WP93+burSL4 Awfm/PK0xYRP9F+yU349JV3qByRiZqb9tp3cG6k53wUzSdEWRVe7TXrMu/4S1ifn77 SiqrtR4ALkeBN/qxKJ9FnIGK5l4xj2j50DD5ZjB4= Received: from mail-pg1-x52c.google.com (mail-pg1-x52c.google.com [IPv6:2607:f8b0:4864:20::52c]) by sourceware.org (Postfix) with ESMTPS id 6AE3B3858C39 for ; Thu, 15 Jul 2021 13:51:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 6AE3B3858C39 Received: by mail-pg1-x52c.google.com with SMTP id o4so1734597pgs.6 for ; Thu, 15 Jul 2021 06:51:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=XGs1852CF/72kdT4chja8zsZAi8rDlHwEgavpInUohw=; b=Ofm+ZqRLdO/hArQ1foDPg5JZ5/xAO+FUtsiPxQCVvpCBtRMySwGee0P06bSAYS6wzD trY4KS929lP+vOtGzKnOz9gxGjJX3X6F07V2f31pO0dBCmTNpdh+kTdgklmGyZBpMcqe QdFKzYFLK9gqEjS4cN7wzYR7xX81GbxkkO7VFlSBDuMQ5fvBOPdtU5QTsNmidO+FWOq1 eBvakcFI0weURv/u5urccAIEQ7u6sa6tWWKyozoH8+Caj2KJGfDWLnvlybcDyhHHOcoo jUAuK25Bj4M0xL5L/UfnYAONo0F46loNEYCnZNGGg11NlzykJnFhWwDlv67R1/SIQpmu b01g== X-Gm-Message-State: AOAM5331eMS80kaOY4fgJnb3ZpEoQT7gCfuP4ts18vw0eOGe825kPYFo CGsqRnG32EvjBbcXe9NhEgp80b7FfHSAjw== X-Google-Smtp-Source: ABdhPJyuHU8ALK5ULPBd3sYJKJIQX+lLnLhFh6qD+bmuma0iRI2StHzWXXffp91vxkKiR5PdfCPqyQ== X-Received: by 2002:a63:6f8c:: with SMTP id k134mr4828017pgc.35.1626357064335; Thu, 15 Jul 2021 06:51:04 -0700 (PDT) Received: from [192.168.1.108] ([177.194.59.218]) by smtp.gmail.com with ESMTPSA id s2sm7601072pgr.12.2021.07.15.06.51.03 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 15 Jul 2021 06:51:04 -0700 (PDT) Subject: Re: [PATCH v3] elf: Fix DTV gap reuse logic (BZ #27135) To: libc-alpha@sourceware.org References: <20210709135001.505521-1-adhemerval.zanella@linaro.org> <20210709150512.GT14854@arm.com> <0c977f4a-248d-c035-a615-852adee670a1@linaro.org> <76323d51-f54d-29c1-1a72-3b439c521f44@redhat.com> <2ad90aa2-bae0-803e-8099-c91fd6641236@linux.ibm.com> Message-ID: Date: Thu, 15 Jul 2021 10:51:01 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <2ad90aa2-bae0-803e-8099-c91fd6641236@linux.ibm.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit 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: Adhemerval Zanella via Libc-alpha Reply-To: Adhemerval Zanella Errors-To: libc-alpha-bounces+e=80x24.org@sourceware.org Sender: "Libc-alpha" On 15/07/2021 10:36, Stefan Liebler via Libc-alpha wrote: > On 14/07/2021 20:11, Adhemerval Zanella via Libc-alpha wrote: >> >> >> On 14/07/2021 13:57, Carlos O'Donell wrote: >>> On 7/14/21 9:52 AM, Adhemerval Zanella wrote: >>>> >>>> >>>> On 09/07/2021 12:05, Szabolcs Nagy wrote: >>>>> The 07/09/2021 10:50, Adhemerval Zanella wrote: >>>>>> Changes from previous version: >>>>>> >>>>>> - Fix commit message and add a line about the bug fixes. >>>>>> - Use atomic operation while setting the slotinfo. >>>>>> - Use test_verbose on tst-tls20.c. >>>>>> >>>>>> --- >>>>>> >>>>>> This is updated version of the 572bd547d57a (reverted by 40ebfd016ad2) >>>>>> that fixes the _dl_next_tls_modid issues. >>>>>> >>>>>> This issue with 572bd547d57a patch is the DTV entry will be only >>>>>> update on dl_open_worker() with the update_tls_slotinfo() call after >>>>>> all dependencies are being processed by _dl_map_object_deps(). However >>>>>> _dl_map_object_deps() itself might call _dl_next_tls_modid(), and since >>>>>> the _dl_tls_dtv_slotinfo_list::map is not yet set the entry will be >>>>>> wrongly reused. >>>>>> >>>>>> This patch fixes by renaming the _dl_next_tls_modid() function to >>>>>> _dl_assign_tls_modid() and by passing the link_map so it can set >>>>>> the slotinfo value so a so subsequente _dl_next_tls_modid() call will >>>>>> see the entry as allocated. >>>>> >>>>> this paragraph still has 'so a so subsequente' >>>>> and i would add the bug number into the first sentence. >>>> >>>> Fixed. >>>> >>>>> >>>>>> >>>>>> The intermediary value is cleared up on remove_slotinfo() for the case >>>>>> a library fails to load with RTLD_NOW. >>>>>> >>>>>> This patch fixes BZ #27135. >>>>>> >>>>>> Checked on x86_64-linux-gnu. >>>>> >>>>> the patch looks ok to me, with the commit message >>>>> and the comment issue below fixed. >>>>> >>>>> Reviewed-by: Szabolcs Nagy >>>> >>>> Carlos, is it for push? >>> >>> It's a non-ABI bug fix, so we can push it. Thanks for asking. >>> >> >> And it is in, let's hope it does not brake anything again ;) >> > > Hi Adhemerval, > > I'm getting a segfault on s390x in elf/tst-tls20. It is at the end of > do_test() when the stack-protector-canary is compared. > > I'm also getting such an error on x86_64, > $ /configure --prefix=/usr --enable-stack-protector=strong > $ make > $ make subdirs=elf check > $ make t=elf/tst-tls20 test > ... > *** stack smashing detected ***: terminated > make[2]: Leaving directory 'glibc/elf' > FAIL: elf/tst-tls20 > original exit status 1 > Didn't expect signal from child: got `Aborted' > > > If configuring without --enable-stack-protector=strong, then > elf/tst-tls20 succeeds. > > Can you please have a look? Sigh, it is overlook in array access. I reproduced it on x86_64 as well, this should fix it: diff --git a/elf/tst-tls20.c b/elf/tst-tls20.c index d8d04fe574..831c3336c9 100644 --- a/elf/tst-tls20.c +++ b/elf/tst-tls20.c @@ -226,12 +226,12 @@ do_test_dependency (void) int mods[nmods]; /* We use '0' as indication for a gap, to avoid the dlclose on iteration cleanup. */ - for (int n = 1; n <= nmods; n++) + for (int n = 1; n < nmods; n++) { load_mod (n); mods[n] = n; } - for (int n = 1; n <= nmods; n++) + for (int n = 1; n < nmods; n++) { if (!is_mod_set (g, n)) { @@ -304,12 +304,12 @@ do_test_invalid_dependency (bool bind_now) int mods[nmods]; /* We use '0' as indication for a gap, to avoid the dlclose on iteration cleanup. */ - for (int n = 1; n <= nmods; n++) + for (int n = 1; n < nmods; n++) { load_mod (n); mods[n] = n; } - for (int n = 1; n <= nmods; n++) + for (int n = 1; n < nmods; n++) { if (!is_mod_set (g, n)) {