This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch bfd]: Prevent possible buffer overflow on pdata-section sorting


On Thu, Apr 07, 2011 at 04:31:45PM +0200, Kai Tietz wrote:
> 2011/4/7 Alan Modra <amodra@gmail.com>:
> > 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]