From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5546 invoked by alias); 9 Apr 2011 04:40:52 -0000 Received: (qmail 5537 invoked by uid 22791); 9 Apr 2011 04:40:51 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,TW_BJ X-Spam-Check-By: sourceware.org Received: from mail-pz0-f41.google.com (HELO mail-pz0-f41.google.com) (209.85.210.41) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 09 Apr 2011 04:40:47 +0000 Received: by pzk32 with SMTP id 32so1935870pzk.0 for ; Fri, 08 Apr 2011 21:40:47 -0700 (PDT) Received: by 10.142.14.1 with SMTP id 1mr2555903wfn.239.1302323703736; Fri, 08 Apr 2011 21:35:03 -0700 (PDT) Received: from bubble.grove.modra.org ([115.187.252.19]) by mx.google.com with ESMTPS id z10sm4569854wfj.0.2011.04.08.21.35.00 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 08 Apr 2011 21:35:02 -0700 (PDT) Received: by bubble.grove.modra.org (Postfix, from userid 1000) id 99245170C1A4; Sat, 9 Apr 2011 14:04:56 +0930 (CST) Date: Sat, 09 Apr 2011 04:40:00 -0000 From: Alan Modra To: Kai Tietz Cc: Binutils , Nick Clifton Subject: Re: [patch bfd]: Prevent possible buffer overflow on pdata-section sorting Message-ID: <20110409043456.GG19002@bubble.grove.modra.org> Mail-Followup-To: Kai Tietz , Binutils , Nick Clifton References: <20110407010943.GW19002@bubble.grove.modra.org> <20110407085238.GZ19002@bubble.grove.modra.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-IsSubscribed: yes Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org X-SW-Source: 2011-04/txt/msg00132.txt.bz2 On Thu, Apr 07, 2011 at 04:31:45PM +0200, Kai Tietz wrote: > 2011/4/7 Alan Modra : > > On Thu, Apr 07, 2011 at 08:15:42AM +0200, Kai Tietz wrote: > >> Hmm, not sure. > > > > Well, I'm 99% sure. :-)  rawsize on an output section, if non-zero, is > > just a stale size at bfd_final_link. > > So this 1% hits. I changed locally to use here just sec->size and I > found that pdata section doesn't get sorted proper anymore. (you can > verify this by objdump -x and it prints warnings about not ascending > data). Ah, what I missed seeing is that coff_compute_section_file_positions is bumping the section size here: #ifdef COFF_IMAGE_WITH_PE /* Set the padded size. */ current->size = (current->size + page_size -1) & -page_size; #endif Obviously, you do want the size of data before this padding is added, but it's only a fluke that rawsize happens to be set correctly. (You get it from the lang_reset_memory_regions call during preliminary section sizing in ldlang.c:strip_excluded_output_sections.) That seems a little unreliable to me. I'd be happier if in coff_compute_section_file_positions you always set rawsize in the loop that is padding section size (do it before any block of code that changes section size!). Then just use sec->rawsize in your peXXigen.c patch. I'll preapprove those changes. -- Alan Modra Australia Development Lab, IBM