public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: "h.becker" <becker.ismaning@freenet.de>
To: Kai Tietz <ktietz70@googlemail.com>
Cc: Binutils <binutils@sourceware.org>, Nick Clifton <nickc@redhat.com>
Subject: Re: [patch bfd]: Prevent possible buffer overflow on pdata-section sorting
Date: Wed, 06 Apr 2011 21:55:00 -0000	[thread overview]
Message-ID: <4D9D2645.9000000@freenet.de> (raw)
In-Reply-To: <BANLkTimv7dy1SPBi=dKP+fnWayX13VpU7g@mail.gmail.com>

The underlying problem is how the size of the buffer is calculated. It's 
size is the maximum of the input sections. However, the sort is for the 
pdata output section. Obviously there is no problem as long as there is 
at least one input section big enough to hold the collected pdata.

I don't want to argue about the fix, what I have is similar to what is 
suggested here. I just want to point out that another option to fix the 
calculation how the size for pfinfo->contents. Or to save that size in 
pinfo as well, so that the buffer can be made bigger whenever that is 
necessary.

Hartmut

Kai Tietz wrote:
> Hello,
> 
> this issue was reported by H. Becker to me.  He found that the code in
> peXXigen.c about pdata-section sorting might cause a buffer-overrun
> for large pdata-data.  By working in private allocated buffer -
> instead of using the pfinfo->contents - avoids this.
> 
> ChangeLog
> 
> 2011-04-06  Kai Tietz
> 
>         * peXXigen.c (_bfd_XXi_final_link_postscripte): Sort pdata in temporary
>         buffer.
> 
> Tested for x86_64-w64-mingw32. Ok for apply?
> 
> Regards,
> Kai
> 

  reply	other threads:[~2011-04-06 21:55 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-06 16:50 Kai Tietz
2011-04-06 21:55 ` h.becker [this message]
2011-04-07  1:09 ` Alan Modra
2011-04-07  5:55   ` Kai Tietz
2011-04-07  6:15     ` Kai Tietz
2011-04-07  8:52       ` Alan Modra
2011-04-07 14:31         ` Kai Tietz
2011-04-09  4:40           ` Alan Modra
2011-04-09  9:50             ` Kai Tietz
     [not found]               ` <20110409131155.GH19002@bubble.grove.modra.org>
     [not found]                 ` <BANLkTikediRDiabar9P0k526O4Pyy_qWSQ@mail.gmail.com>
     [not found]                   ` <20110409140103.GI19002@bubble.grove.modra.org>
2011-04-09 16:07                     ` Kai Tietz
2011-04-11  4:08         ` rawsize and output sections Alan Modra

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4D9D2645.9000000@freenet.de \
    --to=becker.ismaning@freenet.de \
    --cc=binutils@sourceware.org \
    --cc=ktietz70@googlemail.com \
    --cc=nickc@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).