From patchwork Tue Aug 30 08:21:29 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tom de Vries X-Patchwork-Id: 664051 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 3sNhM62VMyz9ryk for ; Tue, 30 Aug 2016 18:21:54 +1000 (AEST) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b=TRO1W5CL; dkim-atps=neutral DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :subject:to:references:cc:from:message-id:date:mime-version :in-reply-to:content-type:content-transfer-encoding; q=dns; s= default; b=pONPVAsI5G8F7U+wZz831DDt7WD85tyELPeKWfqbtVcQubrvJ0J3w Fm7D7DPIzro9rukQUZg9WwzAY/2Drb6VZiwXv5O5LoO7grjo+SFUXsvqRu4MkqWw MfuZRvnFIC+0nuYCBuYvzQc7Z0BgbbfEEFViItvpOx9uK1dKHSpqZk= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :subject:to:references:cc:from:message-id:date:mime-version :in-reply-to:content-type:content-transfer-encoding; s=default; bh=kQ+O1npNAnLBZ1QXPoRDG7kwtR0=; b=TRO1W5CLEoYKjPPmeykbwPVkABDc ctMgBP9IdrrEZBaECesG81T0kntbrzpf69OS4RLmtXoJbIEwM7CMeDOwakWDy4Fi RO2RetPN4nVjVYIaIQClQ2ubZxi5nyJTzJpAfXSjE4DtsSfju8x0ZGNlfZEeUhLF WToD0GxWx7sGY2E= Received: (qmail 81419 invoked by alias); 30 Aug 2016 08:21:46 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 81406 invoked by uid 89); 30 Aug 2016 08:21:46 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL, BAYES_00, RCVD_IN_DNSWL_NONE, SPF_PASS autolearn=ham version=3.3.2 spammy=xd, harmful X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 30 Aug 2016 08:21:44 +0000 Received: from nat-ies.mentorg.com ([192.94.31.2] helo=SVR-IES-FEM-01.mgc.mentorg.com) by relay1.mentorg.com with esmtp id 1beeIe-00055F-Mt from Tom_deVries@mentor.com ; Tue, 30 Aug 2016 01:21:41 -0700 Received: from [127.0.0.1] (137.202.0.76) by SVR-IES-FEM-01.mgc.mentorg.com (137.202.0.104) with Microsoft SMTP Server id 14.3.224.2; Tue, 30 Aug 2016 09:21:38 +0100 Subject: Re: [PATCH] Fix PR64078 To: Bernd Edlinger , Marek Polacek References: <20150907100700.GC30849@redhat.com> <55EF3690.8030201@redhat.com> <55F050D5.3020408@redhat.com> <20150917150026.GC27588@redhat.com> <55FAECA8.3070909@redhat.com> <20150917180838.GE27588@redhat.com> <7fcd8db4-af35-a0fe-fc5a-f7999d0c5fca@mentor.com> CC: Jeff Law , "gcc-patches@gcc.gnu.org" , Jakub Jelinek , "H.J. Lu" From: Tom de Vries Message-ID: <963e7657-0e40-9d73-f199-ffc709761428@mentor.com> Date: Tue, 30 Aug 2016 10:21:29 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: On 29/08/16 18:43, Bernd Edlinger wrote: > Thanks! > > Actually my patch missed to fix one combination: -m32 with -fpic > > make check-gcc-c++ RUNTESTFLAGS="ubsan.exp=object-size-9.c --tool_opts > '-m32 -fpic'" > > FAIL: c-c++-common/ubsan/object-size-9.c -O2 execution test > FAIL: c-c++-common/ubsan/object-size-9.c -O2 -flto > -fno-use-linker-plugin -flto-partition=none execution test > > The problem here is that the functions f2 and f3 access a stack- > based object out of bounds and that is inlined in main and > therefore smashes the return address of main in this case. > > A possible fix could look like follows: > > Index: object-size-9.c > =================================================================== > --- object-size-9.c (revision 239794) > +++ object-size-9.c (working copy) > @@ -93,5 +93,9 @@ > #endif > f4 (12); > f5 (12); > +#ifdef __cplusplus > + /* Stack may be smashed by f2/f3 above. */ > + __builtin_exit (0); > +#endif > return 0; > } > > > Do you think that this should be fixed too? I think it should be fixed. Ideally, we'd prevent the out-of-bounds writes to have harmful effects, but I'm not sure how to enforce that. This works for me: ... ... But I have no idea how stable this solution is. Thanks, - Tom diff --git a/gcc/testsuite/c-c++-common/ubsan/object-size-9.c b/gcc/testsuite/c-c++-common/ubsan/object-size-9.c index 46f1fb9..fec920d 100644 --- a/gcc/testsuite/c-c++-common/ubsan/object-size-9.c +++ b/gcc/testsuite/c-c++-common/ubsan/object-size-9.c @@ -31,6 +31,7 @@ static struct C f2 (int i) { struct C x; + struct C x2; x.d[i] = 'z'; return x; } @@ -45,6 +46,7 @@ static struct C f3 (int i) { struct C x; + struct C x2; char *p = x.d; p += i; *p = 'z';