From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11139 invoked by alias); 7 Apr 2011 06:15:50 -0000 Received: (qmail 11126 invoked by uid 22791); 7 Apr 2011 06:15:48 -0000 X-SWARE-Spam-Status: No, hits=-1.0 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,RFC_ABUSE_POST X-Spam-Check-By: sourceware.org Received: from mail-qw0-f41.google.com (HELO mail-qw0-f41.google.com) (209.85.216.41) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 07 Apr 2011 06:15:43 +0000 Received: by qwa26 with SMTP id 26so1675867qwa.0 for ; Wed, 06 Apr 2011 23:15:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.79.196 with SMTP id q4mr332374qck.132.1302156942756; Wed, 06 Apr 2011 23:15:42 -0700 (PDT) Received: by 10.229.97.206 with HTTP; Wed, 6 Apr 2011 23:15:42 -0700 (PDT) In-Reply-To: References: <20110407010943.GW19002@bubble.grove.modra.org> Date: Thu, 07 Apr 2011 06:15:00 -0000 Message-ID: Subject: Re: [patch bfd]: Prevent possible buffer overflow on pdata-section sorting From: Kai Tietz To: Kai Tietz , Binutils , Nick Clifton Cc: Alan Modra Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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/msg00078.txt.bz2 2011/4/7 Kai Tietz : > 2011/4/7 Alan Modra : >> On Wed, Apr 06, 2011 at 06:50:15PM +0200, Kai Tietz wrote: >>> Hello, >>> >>> this issue was reported by H. Becker to me. =A0He found that the code in >>> peXXigen.c about pdata-section sorting might cause a buffer-overrun >>> for large pdata-data. =A0By working in private allocated buffer - >>> instead of using the pfinfo->contents - avoids this. >>> >>> ChangeLog >>> >>> 2011-04-06 =A0Kai Tietz >>> >>> =A0 =A0 =A0 =A0 * peXXigen.c (_bfd_XXi_final_link_postscripte): Sort pd= ata in temporary >>> =A0 =A0 =A0 =A0 buffer. >>> >>> Tested for x86_64-w64-mingw32. Ok for apply? >>> >>> Regards, >>> Kai >> >>> Index: src/bfd/peXXigen.c >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> --- src.orig/bfd/peXXigen.c =A0 2010-12-21 19:33:07.000000000 +0100 >>> +++ src/bfd/peXXigen.c =A0 =A0 =A0 =A02011-04-06 18:19:45.945394800 +02= 00 >>> @@ -2459,14 +2459,22 @@ _bfd_XXi_final_link_postscript (bfd * ab >>> =A0 =A0 =A0if (sec) >>> =A0 =A0 =A0 =A0{ >>> =A0 =A0 =A0 bfd_size_type x =3D sec->rawsize ? sec->rawsize : sec->size; >> >> Since this is an output section, this should just be sec->size I >> think. =A0See section.c rawsize comment. > > Well, the cause for using here raw_size (I will look into section.c to > read the comment there9 was that we need to sort without alignment. As > it is an output-section, its size might be padded already with > alignment fill, which shouldn't be sorted. =A0But you might be right > here that size is suitable. Hmm, not sure. I think it makes sense to check here for raw_size. In section.c the member size has the following documentation: "The size of the section in octets, as it will be output. Contains a value even if the section has no contents (e.g., the size of <<.bss>>). )". And the rawsize memember has for output-sections the following definition: "For output sections, rawsize holds the section size calculated on a previous linker relaxation pass.", which seems to be the thing we need. It might be a way to allocate section's size, but then sort only in range of rawsize, but not sure if this is necessary, as on output the section alignment get applied again, isn't it? Kai