Message ID | CAGejDpB0W4MBzV5kQ5QUpMGvwdVbMy7gp1r_M-wEUkR7Ysw_=Q@mail.gmail.com |
---|---|
State | New, archived |
Headers |
Return-Path: <gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:6a10:38f:b0:2d5:3c95:9e21 with SMTP id 15csp2191333pxh; Tue, 16 Aug 2022 12:15:14 -0700 (PDT) X-Google-Smtp-Source: AA6agR6t5gisxh389lRNIljpB0fDdywECyZfMO9BIWyZ7XOQLdzD3AwL2y7qld5zVVHE/EhVbLCP X-Received: by 2002:a17:906:8a57:b0:730:8b50:610a with SMTP id gx23-20020a1709068a5700b007308b50610amr14205279ejc.557.1660677314366; Tue, 16 Aug 2022 12:15:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1660677314; cv=none; d=google.com; s=arc-20160816; b=shhTQrH93HcgVDGE6e7gMZ6K0OyBoEzaOhal4Rx8/HLI6a/3IpEjmHQiIrb9xbSpgb oMJFsgbPRUNGkyH8OJQva7+M+sSEwvwomTys5C2G5H+Se2SY/rTqw8o1PSu9ZG2PJRKb tczDzmAr6ERftIj/0F7XkgG1wmg+hSzejsZTv2IroDhu3cEsfO/Qth96yo1IKGrc+1jK dgfhRJDqdNwldJ8qDmxMd7hk7lGRaHwlKTswvb9DNr/4E5Fz184Xrq4GAs2dIyh4vUSQ 1VxNmDuHNK5bdZqFd/oZhaNU2xiOyIE4MaT23k3tr2VkkkiL71D1ybFiCmKx3HHc4UR7 KihA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=sender:errors-to:list-subscribe:list-help:list-post:list-archive :list-unsubscribe:list-id:precedence:to:subject:message-id:date:from :mime-version:dkim-signature:dmarc-filter:delivered-to; bh=Z1Ao8jecsfrliqLKuEG+bkT3krNy9p56wAH9fyWhVNo=; b=D3LVDzHWUem7YahcQuBdb9sGE8Hv65rJOneVKkJAh9tjI0cZXSIK2DoGLIxHe/FKPN b+5zwbZGxEeGIwvXAqtrc03Gx7KuYgaQR3FS+9xyv9J95OcgfANrpPPinmTu8XrXLsuJ jNFh8NKV1S3gs02pamxiWWE2svrf+CpJuJ32kIYcjsSVY6nyZ4/wK9uhE+KDlJVNXhO+ N/rdUJLGF6lyGfI/Xk/UeVbPoc5EBByIzG4YUImpaMYhuIv0wbnjfnVqSbI0fFuhijeG Na032yVbTWsLKvJaACERVPDsjf+QWoTSFNsttn+0HBKAJWwyNdQwkvOvy2w3k0K8wVtb jPBw== ARC-Authentication-Results: i=1; mx.google.com; dkim=neutral (body hash did not verify) header.i=@konscious-net.20210112.gappssmtp.com header.s=20210112 header.b=qkJaVXpT; spf=pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 2620:52:3:1:0:246e:9693:128c as permitted sender) smtp.mailfrom="gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org" Received: from sourceware.org (server2.sourceware.org. [2620:52:3:1:0:246e:9693:128c]) by mx.google.com with ESMTPS id i14-20020a1709064fce00b00738e61897bfsi2007564ejw.233.2022.08.16.12.15.13 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 16 Aug 2022 12:15:14 -0700 (PDT) Received-SPF: pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 2620:52:3:1:0:246e:9693:128c as permitted sender) client-ip=2620:52:3:1:0:246e:9693:128c; Authentication-Results: mx.google.com; dkim=neutral (body hash did not verify) header.i=@konscious-net.20210112.gappssmtp.com header.s=20210112 header.b=qkJaVXpT; spf=pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 2620:52:3:1:0:246e:9693:128c as permitted sender) smtp.mailfrom="gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org" Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 62B40385829F for <ouuuleilei@gmail.com>; Tue, 16 Aug 2022 19:15:08 +0000 (GMT) X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from mail-pl1-x62f.google.com (mail-pl1-x62f.google.com [IPv6:2607:f8b0:4864:20::62f]) by sourceware.org (Postfix) with ESMTPS id 02C6C3858CDA for <gcc-patches@gcc.gnu.org>; Tue, 16 Aug 2022 19:14:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 02C6C3858CDA Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=konscious.net Authentication-Results: sourceware.org; spf=none smtp.mailfrom=konscious.net Received: by mail-pl1-x62f.google.com with SMTP id 20so1460280plo.10 for <gcc-patches@gcc.gnu.org>; Tue, 16 Aug 2022 12:14:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=konscious-net.20210112.gappssmtp.com; s=20210112; h=to:subject:message-id:date:from:mime-version:from:to:cc; bh=yoqsqNBImMepbpJGyYEXfRY/SQkMqfKkzeCtmAwXURk=; b=qkJaVXpTfWsaEX+V8SoBMC1SGoACnMj+efJ2Feu6zNNCNtzVliwKLDHPxjd90u1c2K gGfh8xfDbOOL7tMdXarCKvjiiT9+XeeRFlwKU/HqSLiw4k4AzCYy0t+9bmgGMcxEFNdV 3uHeuxfMkbbyZVm8ZAK2yINIDOwh7t27Xyrv1auu2sDDxKn6yR71MrjSKiE0RmNRZy6s NRP6JN2aO/Vhm4zNZcR1rIw4po2B4Z/L6OWOuPD5BCz2ue7xASrhB99Kji/sIZZphWot UvdPmKWTT03zG/yLXlyAuFfBPCtirDqUZi6CmFcjydU6tw88a1gTrjYo/1uSq6T6zerc Uh3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc; bh=yoqsqNBImMepbpJGyYEXfRY/SQkMqfKkzeCtmAwXURk=; b=vn1FQZywFut8raz9PGhNdenZ6M8d7mKeFUZTUvkAhHgSk9swSPOD4Q5MgClm8g/90p ngb2McFa7joiMRrq3U6iHP5YmTqYTZvGhzLTxVFxrppP/xxnsOXhynqzwK+SNh2E4O4R Srxs7SD5pIxIHYrSsMA+dXrV7/LguQM+Z4i4Y/TN4UnVGnMJkJqsnoQzJwjjJ0JaZw06 NN1Ohn0fhL7U7YW+k0PQwXIcUmNiJPo3mQ1YTAtiuBd5NqckuzZeQkq1CPuY+IXOJAkB Jn1ap9DEQEzImJXPEVPM8bosXpr+G9btzeBjhfzV6TtK8KtTfRCM9t+IUFjanS+oXakO Onow== X-Gm-Message-State: ACgBeo111/9fitixCpv0etEIYmLQ0t1cbJXtCChYrqy4Ujkxi6E3NTTX 3k2bKMtz4oOJx3PYSKMLby/E99e2LvWwTs1CGLRVlYDJtMovwdY= X-Received: by 2002:a17:90a:b794:b0:1f4:feec:2910 with SMTP id m20-20020a17090ab79400b001f4feec2910mr34393pjr.214.1660677282809; Tue, 16 Aug 2022 12:14:42 -0700 (PDT) MIME-Version: 1.0 From: Keef Aragon <keef.aragon@konscious.net> Date: Tue, 16 Aug 2022 12:14:31 -0700 Message-ID: <CAGejDpB0W4MBzV5kQ5QUpMGvwdVbMy7gp1r_M-wEUkR7Ysw_=Q@mail.gmail.com> Subject: [PATCH] bug in emergency cxa pool free() To: libstdc++@gcc.gnu.org, gcc-patches@gcc.gnu.org Content-Type: multipart/mixed; boundary="000000000000877c1605e6608fe3" X-Spam-Status: No, score=-11.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, GIT_PATCH_0, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list <gcc-patches.gcc.gnu.org> List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=unsubscribe> List-Archive: <https://gcc.gnu.org/pipermail/gcc-patches/> List-Post: <mailto:gcc-patches@gcc.gnu.org> List-Help: <mailto:gcc-patches-request@gcc.gnu.org?subject=help> List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=subscribe> Errors-To: gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org Sender: "Gcc-patches" <gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org> X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1741346375572323098?= X-GMAIL-MSGID: =?utf-8?q?1741346375572323098?= |
Series |
bug in emergency cxa pool free()
|
|
Commit Message
Keef Aragon
Aug. 16, 2022, 7:14 p.m. UTC
This probably has never actually affected anyone in practice. The normal ABI implementation just uses malloc and only falls back to the pool on malloc failure. But if that happens a bunch of times the freelist gets out of order which violates some of the invariants of the freelist (as well as the comments that follow the bug). The bug is just a comparison reversal when traversing the freelist in the case where the pointer being returned to the pool is after the existing freelist. I'm not sure what to do as far as the test suite is concerned. It's a private part of the implementation of the exception handling ABI and it can only ever be triggered if malloc fails (repeatedly). So it seems like reproducing it from the external interface will require hooking malloc to forcibly return NULL. But I'm a newb on these lists, so will obediently do as instructed.
Comments
On Tue, Aug 16, 2022 at 9:15 PM Keef Aragon <keef.aragon@konscious.net> wrote: > > This probably has never actually affected anyone in practice. The normal > ABI implementation just uses malloc and only falls back to the pool on > malloc failure. But if that happens a bunch of times the freelist gets out > of order which violates some of the invariants of the freelist (as well as > the comments that follow the bug). The bug is just a comparison reversal > when traversing the freelist in the case where the pointer being returned > to the pool is after the existing freelist. > > I'm not sure what to do as far as the test suite is concerned. It's a > private part of the implementation of the exception handling ABI and it can > only ever be triggered if malloc fails (repeatedly). So it seems like > reproducing it from the external interface will require hooking malloc to > forcibly return NULL. > > But I'm a newb on these lists, so will obediently do as instructed. Oops, that's my fault. For consistency it's probably best written as reinterpret_cast <char *> (e) + sz > reinterpret_cast <char *> ((*fe)) thus diff --git a/libstdc++-v3/libsupc++/eh_alloc.cc b/libstdc++-v3/libsupc++/eh_alloc.cc index c85b9aed40b..68f319869f9 100644 --- a/libstdc++-v3/libsupc++/eh_alloc.cc +++ b/libstdc++-v3/libsupc++/eh_alloc.cc @@ -224,8 +224,8 @@ namespace free_entry **fe; for (fe = &first_free_entry; (*fe)->next - && (reinterpret_cast <char *> ((*fe)->next) - > reinterpret_cast <char *> (e) + sz); + && (reinterpret_cast <char *> (e) + sz + > reinterpret_cast <char *> ((*fe)->next)); fe = &(*fe)->next) ; // If we can merge the next block into us do so and continue The change is OK with that adjustment. I see you do not have write access so I'll test & push it for you. I'm curious how you noticed? Thanks, Richard.
Thank you! I was working on a modified version that I could LD_PRELOAD to investigate some issues I was having in my asynchronous application code. It used a higher order collection of pool instances instead of malloc/free, with extra context (an array of pc register values) packed into the buffer before the refcounted exception. in_pool on the pools in the collection is the safety check to know that the extra context can be safely pulled from the pointer. With that implementation, memory was being leaked because the destruction of one of the pools in the collection requires there to be no more uses of it and quickly checking for that to be the case also needed the ordered invariant to hold (just checking if the freelist the whole arena). On Tue, Aug 16, 2022 at 11:45 PM Richard Biener <richard.guenther@gmail.com> wrote: > On Tue, Aug 16, 2022 at 9:15 PM Keef Aragon <keef.aragon@konscious.net> > wrote: > > > > This probably has never actually affected anyone in practice. The normal > > ABI implementation just uses malloc and only falls back to the pool on > > malloc failure. But if that happens a bunch of times the freelist gets > out > > of order which violates some of the invariants of the freelist (as well > as > > the comments that follow the bug). The bug is just a comparison reversal > > when traversing the freelist in the case where the pointer being returned > > to the pool is after the existing freelist. > > > > I'm not sure what to do as far as the test suite is concerned. It's a > > private part of the implementation of the exception handling ABI and it > can > > only ever be triggered if malloc fails (repeatedly). So it seems like > > reproducing it from the external interface will require hooking malloc to > > forcibly return NULL. > > > > But I'm a newb on these lists, so will obediently do as instructed. > > Oops, that's my fault. > For consistency it's probably best written > as reinterpret_cast <char *> (e) + sz > reinterpret_cast <char *> ((*fe)) > thus > > diff --git a/libstdc++-v3/libsupc++/eh_alloc.cc > b/libstdc++-v3/libsupc++/eh_alloc.cc > index c85b9aed40b..68f319869f9 100644 > --- a/libstdc++-v3/libsupc++/eh_alloc.cc > +++ b/libstdc++-v3/libsupc++/eh_alloc.cc > @@ -224,8 +224,8 @@ namespace > free_entry **fe; > for (fe = &first_free_entry; > (*fe)->next > - && (reinterpret_cast <char *> ((*fe)->next) > - > reinterpret_cast <char *> (e) + sz); > + && (reinterpret_cast <char *> (e) + sz > + > reinterpret_cast <char *> ((*fe)->next)); > fe = &(*fe)->next) > ; > // If we can merge the next block into us do so and continue > > The change is OK with that adjustment. I see you do not have write access > so > I'll test & push it for you. > > I'm curious how you noticed? > > Thanks, > Richard. >
diff --git a/libstdc++-v3/ChangeLog-2022 b/libstdc++-v3/ChangeLog-2022 new file mode 100644 index 00000000000..8057de58539 --- /dev/null +++ b/libstdc++-v3/ChangeLog-2022 @@ -0,0 +1,4 @@ +2022-08-16 Keef Aragon <keef.aragon@konscious.net> + + * libstdc++-v3/libsupc++/eh_alloc.cc: inverse comparison in pool::free + diff --git a/libstdc++-v3/libsupc++/eh_alloc.cc b/libstdc++-v3/libsupc++/eh_alloc.cc index c85b9aed40b..cad2750e3b9 100644 --- a/libstdc++-v3/libsupc++/eh_alloc.cc +++ b/libstdc++-v3/libsupc++/eh_alloc.cc @@ -225,7 +225,7 @@ namespace for (fe = &first_free_entry; (*fe)->next && (reinterpret_cast <char *> ((*fe)->next) - > reinterpret_cast <char *> (e) + sz); + < reinterpret_cast <char *> (e) + sz); fe = &(*fe)->next) ; // If we can merge the next block into us do so and continue