Message ID | 3721784a79c9d2040297304b2a7216d7072ea838.1613390045.git.szabolcs.nagy@arm.com (mailing list archive) |
---|---|
State | Committed |
Commit | 395be7c2184645320c955b0ba214af9fa1ea9675 |
Delegated to: | Adhemerval Zanella Netto |
Headers |
Return-Path: <libc-alpha-bounces@sourceware.org> X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id DA6AD3950434; Mon, 15 Feb 2021 11:57:23 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org DA6AD3950434 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1613390243; bh=fkOptyq0c0zGzDDr27CPVdNZc0LNIa2hJXpVTfn1kDk=; h=To:Subject:Date:In-Reply-To:References:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=fvUV6VW9y+tPS73NhUpUXIxNmx80bZvENLwDEUQ83Iog9qMlHvlX3dX8J0652qoQ2 AyRJrVL0nxCEE+QYClFKP972xr0CWpJklkSe9t2qpwYQuMnGt52GLSDJZL2DpdyD9u wHeobFrQygtTVY7QVKJ8yB0TLmIt9ZfUF4tuLVIQ= X-Original-To: libc-alpha@sourceware.org Delivered-To: libc-alpha@sourceware.org Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2047.outbound.protection.outlook.com [40.107.21.47]) by sourceware.org (Postfix) with ESMTPS id CFE3C395042D for <libc-alpha@sourceware.org>; Mon, 15 Feb 2021 11:57:20 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org CFE3C395042D Received: from AM5PR1001CA0021.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:206:2::34) by AM6PR08MB3685.eurprd08.prod.outlook.com (2603:10a6:20b:6f::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3846.29; Mon, 15 Feb 2021 11:57:19 +0000 Received: from AM5EUR03FT020.eop-EUR03.prod.protection.outlook.com (2603:10a6:206:2:cafe::c7) by AM5PR1001CA0021.outlook.office365.com (2603:10a6:206:2::34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3846.27 via Frontend Transport; Mon, 15 Feb 2021 11:57:19 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; sourceware.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;sourceware.org; dmarc=pass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by AM5EUR03FT020.mail.protection.outlook.com (10.152.16.116) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3846.25 via Frontend Transport; Mon, 15 Feb 2021 11:57:18 +0000 Received: ("Tessian outbound 28c96a6c9d2e:v71"); Mon, 15 Feb 2021 11:57:17 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 7c62917f4cfb6cef X-CR-MTA-TID: 64aa7808 Received: from 83b055a61693.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 21E8600C-EC28-4216-A38A-1D3AA2BD8EDB.1; Mon, 15 Feb 2021 11:57:04 +0000 Received: from EUR01-VE1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 83b055a61693.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Mon, 15 Feb 2021 11:57:04 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=m94dbisz21nXzCEc1G5ylcI2PDd5h3fgVhXyvFQj3YmNup+/KWPLcHvoM1ZvusWEpRS0uZ6FwqQg8PG4Kwc4MIx/7GO1bmYdr7z4Dq8vGG9qq4nlIo2Uq3ZMPj1qEMWQG/5AVpyBuL7XC8TLAFjcM2nyDwUmDQnDEhLZ+41/x8SmSy3ePdFRlP5udSeEb0tHBSl44r5MesXWuTzr4ga3pH0u5gjUbwI4P+nK9l7CQ6rXxmn87JBiT/EVxPD7ZD7BFR/RCAtq7mxr0BWbraTdGiGUb0oCqjdUKDLHL4w1vDVPoVxn5UJPf9LdhQzS0+OxuEfzgBWDSgG58hv2LLaZdw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=fkOptyq0c0zGzDDr27CPVdNZc0LNIa2hJXpVTfn1kDk=; b=cTxEIyx6foepav/oHHERQUZN3j8G0YGNxHEm27k3vu7gf5zKC1NSaF8teOOmdnXRDFkFyaA08B/uhhW+QwAQLBjKWrlo4oNDHTrg0tqJahwoZxvub7wBfp7CO+Y4vhIqi8srik/miX78ar1UQFJf/YDd1s1qsZp8y22PtYMuPRZC0c2XW8+p2K7iEq80R26vJceb4WfzSFWsWs0gDx8Av+hUdGvbDDVo0FctJlOi3gwe8hN7FgCKREhQXid0MBNd+y9ZV0+NQC/xxEgeG3DxlQ2AvkIqHgmA0Ypic/ElxQQHrWzGCxB9z6mpI3qeU4ek3avBQspvbxtmKpdYlxZhTQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none Authentication-Results-Original: sourceware.org; dkim=none (message not signed) header.d=none;sourceware.org; dmarc=none action=none header.from=arm.com; Received: from PA4PR08MB6320.eurprd08.prod.outlook.com (2603:10a6:102:e5::9) by PAXPR08MB6432.eurprd08.prod.outlook.com (2603:10a6:102:154::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3846.26; Mon, 15 Feb 2021 11:57:03 +0000 Received: from PA4PR08MB6320.eurprd08.prod.outlook.com ([fe80::60f0:3773:69b8:e336]) by PA4PR08MB6320.eurprd08.prod.outlook.com ([fe80::60f0:3773:69b8:e336%2]) with mapi id 15.20.3846.042; Mon, 15 Feb 2021 11:57:03 +0000 To: libc-alpha@sourceware.org Subject: [PATCH 02/15] elf: Fix data race in _dl_name_match_p [BZ #21349] Date: Mon, 15 Feb 2021 11:56:51 +0000 Message-Id: <3721784a79c9d2040297304b2a7216d7072ea838.1613390045.git.szabolcs.nagy@arm.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <cover.1613390045.git.szabolcs.nagy@arm.com> References: <cover.1613390045.git.szabolcs.nagy@arm.com> Content-Type: text/plain X-Originating-IP: [217.140.106.49] X-ClientProxiedBy: SN4PR0501CA0124.namprd05.prod.outlook.com (2603:10b6:803:42::41) To PA4PR08MB6320.eurprd08.prod.outlook.com (2603:10a6:102:e5::9) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from localhost.localdomain (217.140.106.49) by SN4PR0501CA0124.namprd05.prod.outlook.com (2603:10b6:803:42::41) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3868.11 via Frontend Transport; Mon, 15 Feb 2021 11:57:02 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 1b3d50d0-a810-49b4-7696-08d8d1a8d806 X-MS-TrafficTypeDiagnostic: PAXPR08MB6432:|AM6PR08MB3685: X-Microsoft-Antispam-PRVS: <AM6PR08MB36852117C5181FC7D9D170C9ED889@AM6PR08MB3685.eurprd08.prod.outlook.com> x-checkrecipientrouted: true NoDisclaimer: true X-MS-Oob-TLC-OOBClassifiers: OLM:9508;OLM:9508; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: wMnF/vLfZaAECM0mmbLDN8HHqeUqhG9dljuDe46QaF7Og46KLjIXnYUusid1T+fl+P9xT156SVaaY7vvsjPgkMqSsQStq+YqVywNgW62O/XCXhLJbQ6KGwY4BtefAHt214SCYaHw+Zz3czCAnZwJB+OW7FUSqjd36VE+aJ5G3odIQPrN+RyIwIWMPblsNbPqt/DTaI6S95WdKw+95MYNP5hxqECzJYGG2PBqA4La10s4lyZmlgVr9N49x59TuoDymiTY5I5zXhokaJC7a1BcqXF1sgWKYlJF1dYFqLNeJpe8oN8rLTb0MeArsYtS6OynPs+jRIpH7pgV7oDAgrFM85gLlib4KsIlzTJzArIPLqNyoI+FCxufByfcz6MXXfTyvaG4VW6F6PCgYw9QsxdcfuDS5TjYBSmXcWYZ8+swpYwJtawYRsyh6pwriqMRvfRqQwqU5koxWqr2xQ23EhzgJ3jqo7itY0cGQvfQ9wIG9fOvXqI8Rx9s00U9lX8eigHll4q+3Il1zVPy1Fm9OztaTyJ9Xcqi66/WzXniqXbMd2yfxaxqLcfggGAxQmN63Sy2AZZ53mrJHDaq93gRCpxipw== X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PA4PR08MB6320.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(376002)(136003)(346002)(366004)(39850400004)(69590400012)(83380400001)(6512007)(6916009)(66946007)(66476007)(316002)(66556008)(186003)(52116002)(86362001)(8936002)(36756003)(6486002)(5660300002)(478600001)(26005)(6506007)(4326008)(956004)(6666004)(16526019)(2616005)(8676002)(2906002)(44832011); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: JFcGDqHf/uGUxoaPW83OK3sq0ExZYJQFRShgWKuXqwfLyrR+ope//EV9LCVbAUwY7HtQG9JKYr0EpjDXdOHTJ+WOzWOXeeTyaQrd06Ic4VQ+1p3KtDO/tImtU04z8u78WtTCcCZRHPanR2Mv6DXY10NKBrB/5+mMIBqVzkihm68e3TWoDkcytb0hcX8b0so8BubYQZq0KGuAvxTEJJMc6ShYIwwslHn19J7wORGnn96dta5lujb+tg27qx+INPGbwZzsEJWhMQhEip6pi6c6PENHuHyTQp/e5UXXWQtJGzGBN0SaRNE/KkJaFTfm1C78kcXG7BbPrmXjGZE/hxcxg1zDhcOMjfdJiE3Cyk+GUmxrqQeA6z70Yth2jYN2XPbRZzu6NBM6WF82qpmKR1PQI/Y+1+YCCXWHx9q2eNnC7c2FDUSPlF32y+DTgjBGKFcTaEJ9LY/QskU/hVMYLCYmRyxDZqIdTbYn8Gy7+fSoEE/F21BTW8KkCCR3/PjXWu97pdhYG+6zYrLK3fI5LQnLngG1/BmILNvN1TxiQLAJlVAEK6zmUdNPWeykW7LjujuMR7IU5Xtzg4Yr0q2tBhII7E+fc+44WjdnUOxR8bO8dkgQ+ztWcqzZrucF1J/Fec2oX4fQeuQZxK1JBb/WVGxm/D0jxxfkFG+ENDZ+mtq3yBtvnw31vlYFUTV7bqhM8u69eAP0gN6nXdh0eBFrTZtX20HdrtzaaqgJGYuRrpP+FqqxbFC7jfKE6ZTDcBDzacITBVzWmm55tDQ7eIXMyYwWNaiDGxySKaNxXX/0trbVbDfWw8IbpIcXSOA8nyq9UJ3vtuYveS3j7hDHXRFbhM0bfBLSew428vz/N57BWW6X102E6dpNoteUXgzKsps5OEMUb/lgbPYzZ8i5gMpAP83wYnyYrqUwNi7TvhvgnaanXo8ynWcroBnboyWwvdcC9vQtw4PCYhFA6dSbqNd6reYQgHXG9bXf3v11+7RwJIdnLzn0Im4i4r8G9KP4vPWlfa9x/4p8J3RW24Yjn7NbW8j6nxfh+ovR+BdF0x3I5cwcM3KNNe9iLw+AVd0UoQIO0WDvPLfGbs83LGsLswGqHAhpCgp01u3Anj48iA0GVetH/fN2C8ZSV6DN4hpK5PXwPH1lGS3hTAUswePBTPStggRKboMIuXo0R3wc/toRQHDVYBu/iUJ0MbMazM/CItRrxuIx4792xgguzLvLDifL1LY2miQ5P0Ono4LcB6Ks6D6Um9vMlPU4yLy5JBzpE43vU8fOo3JiP2f1aTJp+XOAFSOvG1r8trkxdZYQJxNNBeeFNT5LNJ9tQIn4S7OCkVHiMuhX X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAXPR08MB6432 Original-Authentication-Results: sourceware.org; dkim=none (message not signed) header.d=none; sourceware.org; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: AM5EUR03FT020.eop-EUR03.prod.protection.outlook.com X-MS-Office365-Filtering-Correlation-Id-Prvs: 1566bf33-91e4-4d11-d337-08d8d1a8cf40 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: Gv4ESyYs2FgAbqZw+RZ90XPUp2RchxPgRNWbbpDQPZge4jPFImXdtKejMZ1cGoFanqZak1q7GngQP2xzp2sL5zIlqixko7reFOT8Rh8s30cU9FbTa8UjKqVDz7qL88a1QwiN7m5yTrlW8rpu2aoNjFHHxOUDSw5pvR64FuuSFZbZlrWM043FETN+9MLB2vCdagc3+XXgpXg7oEgPMj1fTmC/8KXmqBuYE98vEGpL9tOZzsVkxd8O1k6RjSF4nPNJ6N7Rh7KMcBbrwhbinnDQL+L4MPYPfNuRxkxtS39wLy1QnuHPdu4Sqxw9v/OmbJJbhhwjn8CJHqGx0nE9sbKWS+hwFLMXoFRkAGjNWIXdlQCduTHXlW4aAlQ5CJDtF9PE983LozfU60ZJHV5fEV7hNRaV2MzKgOK9uv8VCtVl3QBiXAiHmDv31fEN3Mv7WJY9MkxfFPCN+NTwx89LhL4RvfJkJ/bk2MVw4WiGmZJsmnZZA8nMcd32jfTVI6SdtGWMu1TiJ/Oxy4qq1kZ5uw9/wBMuw2FAJP5UXNy5b0OKMkXyuwXdSp2vb898bpwsis+Cg6xXt08p5WmjOrnxGBgs4B+dPyPxSLA+6zMy/SC0f+ZDzDTTzjm2R2O9rV6OHvYD7BMbrbCWhXDtA+8CrYkR9uJbWf1Y+wxENlK9NYGKxnZkGlh6KeNaNfjCQqYmJamR X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFS:(4636009)(346002)(136003)(396003)(376002)(39850400004)(46966006)(36840700001)(478600001)(69590400012)(316002)(6666004)(956004)(6486002)(36756003)(6916009)(8936002)(4326008)(8676002)(86362001)(83380400001)(36860700001)(47076005)(2906002)(6512007)(44832011)(70586007)(107886003)(26005)(6506007)(81166007)(2616005)(186003)(82310400003)(16526019)(5660300002)(356005)(336012)(70206006)(82740400003); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Feb 2021 11:57:18.1318 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 1b3d50d0-a810-49b4-7696-08d8d1a8d806 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-AuthSource: AM5EUR03FT020.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB3685 X-Spam-Status: No, score=-13.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, GIT_PATCH_0, MSGID_FROM_MTA_HEADER, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_PASS, SPF_PASS, TXREP, UNPARSEABLE_RELAY autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list <libc-alpha.sourceware.org> List-Unsubscribe: <https://sourceware.org/mailman/options/libc-alpha>, <mailto:libc-alpha-request@sourceware.org?subject=unsubscribe> List-Archive: <https://sourceware.org/pipermail/libc-alpha/> List-Post: <mailto:libc-alpha@sourceware.org> List-Help: <mailto:libc-alpha-request@sourceware.org?subject=help> List-Subscribe: <https://sourceware.org/mailman/listinfo/libc-alpha>, <mailto:libc-alpha-request@sourceware.org?subject=subscribe> From: Szabolcs Nagy via Libc-alpha <libc-alpha@sourceware.org> Reply-To: Szabolcs Nagy <szabolcs.nagy@arm.com> Cc: Maninder Singh <maninder1.s@samsung.com> Errors-To: libc-alpha-bounces@sourceware.org Sender: "Libc-alpha" <libc-alpha-bounces@sourceware.org> |
Series |
Dynamic TLS related data race fixes
|
|
Commit Message
Szabolcs Nagy
Feb. 15, 2021, 11:56 a.m. UTC
From: Maninder Singh <maninder1.s@samsung.com>
dlopen updates libname_list by writing to lastp->next, but concurrent
reads in _dl_name_match_p were not synchronized when it was called
without holding GL(dl_load_lock), which can happen during lazy symbol
resolution.
This patch fixes the race between _dl_name_match_p reading lastp->next
and add_name_to_object writing to it. This could cause segfault on
targets with weak memory order when lastp->next->name is read, which
was observed on an arm system. Fixes bug 21349.
(Code is from Maninder Singh, comments and description is from Szabolcs
Nagy.)
Co-authored-by: Szabolcs Nagy <szabolcs.nagy@arm.com>
---
elf/dl-load.c | 18 +++++++++++++++++-
elf/dl-misc.c | 4 +++-
2 files changed, 20 insertions(+), 2 deletions(-)
Comments
Hi Szabolcs, Thanks for trying this patch again. Please add Vaneet Name in co authered also. >From: Maninder Singh <maninder1.s@samsung.com> > >dlopen updates libname_list by writing to lastp->next, but concurrent >reads in _dl_name_match_p were not synchronized when it was called >without holding GL(dl_load_lock), which can happen during lazy symbol >resolution. > >This patch fixes the race between _dl_name_match_p reading lastp->next >and add_name_to_object writing to it. This could cause segfault on >targets with weak memory order when lastp->next->name is read, which >was observed on an arm system. Fixes bug 21349. > >(Code is from Maninder Singh, comments and description is from Szabolcs >Nagy.) > >Co-authored-by: Szabolcs Nagy <szabolcs.nagy@arm.com> Co-authored-by: Vaneet Narang <v.narang@samsung.com> because issue was analysed by vaneet firstly. Thanks Again, Maninder Singh
On 15/02/2021 08:56, Szabolcs Nagy via Libc-alpha wrote: > From: Maninder Singh <maninder1.s@samsung.com> > > dlopen updates libname_list by writing to lastp->next, but concurrent > reads in _dl_name_match_p were not synchronized when it was called > without holding GL(dl_load_lock), which can happen during lazy symbol > resolution. > > This patch fixes the race between _dl_name_match_p reading lastp->next > and add_name_to_object writing to it. This could cause segfault on > targets with weak memory order when lastp->next->name is read, which > was observed on an arm system. Fixes bug 21349. > > (Code is from Maninder Singh, comments and description is from Szabolcs > Nagy.) > > Co-authored-by: Szabolcs Nagy <szabolcs.nagy@arm.com> I couldn't reproduce with the example provided in the bugzilla (on both aarch64 and arm machines), but the explanation and the fix sounds logical. I guess a testcase will be hard to create an exercise the issue. LGTM, thanks. Reviewed-by; Adhemerval Zanella <adhemerval.zanella@linaro.org> > --- > elf/dl-load.c | 18 +++++++++++++++++- > elf/dl-misc.c | 4 +++- > 2 files changed, 20 insertions(+), 2 deletions(-) > > diff --git a/elf/dl-load.c b/elf/dl-load.c > index 9e2089cfaa..be54bafad5 100644 > --- a/elf/dl-load.c > +++ b/elf/dl-load.c > @@ -438,7 +438,23 @@ add_name_to_object (struct link_map *l, const char *name) > newname->name = memcpy (newname + 1, name, name_len); > newname->next = NULL; > newname->dont_free = 0; > - lastp->next = newname; > + /* CONCURRENCY NOTES: > + > + Make sure the initialization of newname happens before its address is > + read from the lastp->next store below. > + > + GL(dl_load_lock) is held here (and by other writers, e.g. dlclose), so > + readers of libname_list->next (e.g. _dl_check_caller or the reads above) > + can use that for synchronization, however the read in _dl_name_match_p > + may be executed without holding the lock during _dl_runtime_resolve > + (i.e. lazy symbol resolution when a function of library l is called). > + > + The release MO store below synchronizes with the acquire MO load in > + _dl_name_match_p. Other writes need to synchronize with that load too, > + however those happen either early when the process is single threaded > + (dl_main) or when the library is unloaded (dlclose) and the user has to > + synchronize library calls with unloading. */ > + atomic_store_release (&lastp->next, newname); > } > > /* Standard search directories. */ > diff --git a/elf/dl-misc.c b/elf/dl-misc.c > index 082f75f459..d4803bba4e 100644 > --- a/elf/dl-misc.c > +++ b/elf/dl-misc.c > @@ -347,7 +347,9 @@ _dl_name_match_p (const char *name, const struct link_map *map) > if (strcmp (name, runp->name) == 0) > return 1; > else > - runp = runp->next; > + /* Synchronize with the release MO store in add_name_to_object. > + See CONCURRENCY NOTES in add_name_to_object in dl-load.c. */ > + runp = atomic_load_acquire (&runp->next); > > return 0; > } >
The 04/01/2021 11:01, Adhemerval Zanella wrote: > On 15/02/2021 08:56, Szabolcs Nagy via Libc-alpha wrote: > > From: Maninder Singh <maninder1.s@samsung.com> > > > > dlopen updates libname_list by writing to lastp->next, but concurrent > > reads in _dl_name_match_p were not synchronized when it was called > > without holding GL(dl_load_lock), which can happen during lazy symbol > > resolution. > > > > This patch fixes the race between _dl_name_match_p reading lastp->next > > and add_name_to_object writing to it. This could cause segfault on > > targets with weak memory order when lastp->next->name is read, which > > was observed on an arm system. Fixes bug 21349. > > > > (Code is from Maninder Singh, comments and description is from Szabolcs > > Nagy.) > > > > Co-authored-by: Szabolcs Nagy <szabolcs.nagy@arm.com> > > I couldn't reproduce with the example provided in the bugzilla (on both > aarch64 and arm machines), but the explanation and the fix sounds logical. > I guess a testcase will be hard to create an exercise the issue. > > LGTM, thanks. > > Reviewed-by; Adhemerval Zanella <adhemerval.zanella@linaro.org> thanks, committed at 395be7c2184645320c955b0ba214af9fa1ea9675
diff --git a/elf/dl-load.c b/elf/dl-load.c index 9e2089cfaa..be54bafad5 100644 --- a/elf/dl-load.c +++ b/elf/dl-load.c @@ -438,7 +438,23 @@ add_name_to_object (struct link_map *l, const char *name) newname->name = memcpy (newname + 1, name, name_len); newname->next = NULL; newname->dont_free = 0; - lastp->next = newname; + /* CONCURRENCY NOTES: + + Make sure the initialization of newname happens before its address is + read from the lastp->next store below. + + GL(dl_load_lock) is held here (and by other writers, e.g. dlclose), so + readers of libname_list->next (e.g. _dl_check_caller or the reads above) + can use that for synchronization, however the read in _dl_name_match_p + may be executed without holding the lock during _dl_runtime_resolve + (i.e. lazy symbol resolution when a function of library l is called). + + The release MO store below synchronizes with the acquire MO load in + _dl_name_match_p. Other writes need to synchronize with that load too, + however those happen either early when the process is single threaded + (dl_main) or when the library is unloaded (dlclose) and the user has to + synchronize library calls with unloading. */ + atomic_store_release (&lastp->next, newname); } /* Standard search directories. */ diff --git a/elf/dl-misc.c b/elf/dl-misc.c index 082f75f459..d4803bba4e 100644 --- a/elf/dl-misc.c +++ b/elf/dl-misc.c @@ -347,7 +347,9 @@ _dl_name_match_p (const char *name, const struct link_map *map) if (strcmp (name, runp->name) == 0) return 1; else - runp = runp->next; + /* Synchronize with the release MO store in add_name_to_object. + See CONCURRENCY NOTES in add_name_to_object in dl-load.c. */ + runp = atomic_load_acquire (&runp->next); return 0; }