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
>
next prev parent 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).