From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 121673 invoked by alias); 16 Sep 2015 09:15:22 -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 117936 invoked by uid 89); 16 Sep 2015 09:15:17 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-yk0-f172.google.com Received: from mail-yk0-f172.google.com (HELO mail-yk0-f172.google.com) (209.85.160.172) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Wed, 16 Sep 2015 09:15:16 +0000 Received: by ykdt18 with SMTP id t18so192298896ykd.3 for ; Wed, 16 Sep 2015 02:15:14 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.170.74.85 with SMTP id q82mr27319135ykq.94.1442394914661; Wed, 16 Sep 2015 02:15:14 -0700 (PDT) Received: by 10.37.93.136 with HTTP; Wed, 16 Sep 2015 02:15:14 -0700 (PDT) In-Reply-To: References: Date: Wed, 16 Sep 2015 09:29:00 -0000 Message-ID: Subject: Re: [PATCH, i386]: Fix PR 67484, asan detects heap-use-after-free with target options From: Richard Biener To: Uros Bizjak Cc: "gcc-patches@gcc.gnu.org" Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2015-09/txt/msg01160.txt.bz2 And it is initialized via void cl_target_option_save (struct cl_target_option *ptr, struct gcc_options *opts) { if (targetm.target_option.save) targetm.target_option.save (ptr, opts); ptr->x_recip_mask = opts->x_recip_mask; ptr->x_ix86_isa_flags = opts->x_ix86_isa_flags; ptr->x_ix86_fpmath = opts->x_ix86_fpmath; ptr->x_target_flags = opts->x_target_flags; } which uses a target hook to copy from gcc_options to cl_target_options... (what a maze), and ix86_function_specific_save also plain copies the pointers. Richard. On Wed, Sep 16, 2015 at 11:08 AM, Richard Biener wrote: > I see in gtype-desc.c: > > void > gt_ggc_mx_cl_target_option (void *x_p) > { > struct cl_target_option * const x = (struct cl_target_option *)x_p; > if (ggc_test_and_set_mark (x)) > { > gt_ggc_m_S ((*x).x_ix86_arch_string); > gt_ggc_m_S ((*x).x_ix86_recip_name); > gt_ggc_m_S ((*x).x_ix86_tune_ctrl_string); > gt_ggc_m_S ((*x).x_ix86_tune_memcpy_strategy); > gt_ggc_m_S ((*x).x_ix86_tune_memset_strategy); > gt_ggc_m_S ((*x).x_ix86_tune_string); > } > > so it certainly does not expect heap allocated strings in > ix86_arch_string and friends. > > Richard. > > On Wed, Sep 16, 2015 at 10:59 AM, Uros Bizjak wrote: >> On Wed, Sep 16, 2015 at 10:45 AM, Richard Biener >> wrote: >> >>>> As mentioned in the PR, ix86_valid_target_attribute_tree creates >>>> temporary copies of current options strings and saves *pointers* to >>>> these copies with build_target_option_node. A couple of lines below, >>>> these temporary copies are freed, leaving dangling pointers in the >>>> saved structure. >>>> >>>> Use xstrndup to create permanent copy of string on the heap. This will >>>> however create a small leak, as this copy is never deallocated. >>>> >>>> There is no test infrastructure to check for memory errors, so there >>>> is no testcase added. >>>> >>>> 2015-09-15 Uros Bizjak >>>> >>>> PR target/67484 >>>> * config/i386/i386.c (ix86_valid_target_attribute_tree): >>>> Use xstrdup to copy option_strings to opts->x_ix86_arch_string and >>>> opts->x_ix86_tune_string. >>>> >>>> Bootstrapped and regression tested on x86_64-linux-gnu {,-m32}. >>>> >>>> I'll wait a couple of days for possible comments on the above solution. >>> >>> I thought we have a custom destructor for target_option_node. Ah, no, >>> that was for target_globals. I suppose we could add one to cl_target_option >>> as well. Note that currently the strings are not GTY((skip)) so it seems >>> we expect ggc allocated strings there? Which means the xstrdup in >>> ix86_valid_target_attribute_inner_p should be ggc_strdup? >> >> This is a bit over my knowledge of option processing, but please note >> that the only function that performs non-recursive call to >> ix86_valid_target_attribute_inner_p also frees the strings, allocated >> by mentioned function. >> >> Uros.