From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 67894 invoked by alias); 4 Dec 2018 23:32:30 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 67882 invoked by uid 89); 4 Dec 2018 23:32:30 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-11.9 required=5.0 tests=BAYES_00,GIT_PATCH_2,GIT_PATCH_3,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 04 Dec 2018 23:32:28 +0000 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 9AF2388E48; Tue, 4 Dec 2018 23:32:27 +0000 (UTC) Received: from tucnak.zalov.cz (ovpn-117-214.ams2.redhat.com [10.36.117.214]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 3BECD5C26A; Tue, 4 Dec 2018 23:32:27 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.15.2/8.15.2) with ESMTP id wB4NWPFu009656; Wed, 5 Dec 2018 00:32:25 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.15.2/8.15.2/Submit) id wB4NWN6s009655; Wed, 5 Dec 2018 00:32:23 +0100 Date: Tue, 04 Dec 2018 23:32:00 -0000 From: Jakub Jelinek To: Richard Biener Cc: gcc-patches@gcc.gnu.org Subject: [PATCH] Fix -fsanitize=address -fstack-protector* (PR sanitizer/88333) Message-ID: <20181204233223.GE12380@tucnak> Reply-To: Jakub Jelinek MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.9.2 (2017-12-15) X-IsSubscribed: yes X-SW-Source: 2018-12/txt/msg00245.txt.bz2 Hi! The current asan.c code requires that the whole block of vars starts and ends on ASAN_RED_ZONE_SIZE (i.e. 32 byte) boundary, so that it is on 4 byte boundary in the shadow memory. Normally it is, when frame_offset starts at 0, but with -fstack-protector there is the guard above it and in that case following patch is needed to realign the end of the block. Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? 2018-12-04 Jakub Jelinek PR sanitizer/88333 * cfgexpand.c (expand_stack_vars): If asan_vec is empty, start with aligning frame offset to ASAN_RED_ZONE_SIZE bytes. * c-c++-common/asan/pr88333.c: New test. --- gcc/cfgexpand.c.jj 2018-11-30 19:59:59.676789914 +0100 +++ gcc/cfgexpand.c 2018-12-04 11:25:55.549672029 +0100 @@ -1124,6 +1124,11 @@ expand_stack_vars (bool (*pred) (size_t) && frame_offset.is_constant (&prev_offset) && stack_vars[i].size.is_constant ()) { + if (data->asan_vec.is_empty ()) + { + alloc_stack_frame_space (0, ASAN_RED_ZONE_SIZE); + prev_offset = frame_offset.to_constant (); + } prev_offset = align_base (prev_offset, MAX (alignb, ASAN_MIN_RED_ZONE_SIZE), !FRAME_GROWS_DOWNWARD); --- gcc/testsuite/c-c++-common/asan/pr88333.c.jj 2018-12-04 12:14:44.329877625 +0100 +++ gcc/testsuite/c-c++-common/asan/pr88333.c 2018-12-04 12:14:34.804033303 +0100 @@ -0,0 +1,12 @@ +/* PR sanitizer/88333 */ +/* { dg-do compile { target fstack_protector } } */ +/* { dg-options "-fstack-protector-strong -fsanitize=address" } */ + +void bar (int *); + +void +foo (void) +{ + int c; + bar (&c); +} Jakub