From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5398 invoked by alias); 6 Apr 2011 21:55:51 -0000 Received: (qmail 5385 invoked by uid 22791); 6 Apr 2011 21:55:50 -0000 X-SWARE-Spam-Status: No, hits=1.1 required=5.0 tests=BAYES_00,DATE_IN_FUTURE_03_06,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mout5.freenet.de (HELO mout5.freenet.de) (195.4.92.95) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 06 Apr 2011 21:55:46 +0000 Received: from [195.4.92.15] (helo=5.mx.freenet.de) by mout5.freenet.de with esmtpa (ID becker.ismaning@freenet.de) (port 25) (Exim 4.72 #5) id 1Q7ahT-0008Fl-Rr; Wed, 06 Apr 2011 23:55:43 +0200 Received: from ip-80-226-229-146.vodafone-net.de ([80.226.229.146]:58087 helo=[10.230.199.123]) by 5.mx.freenet.de with esmtpsa (ID becker.ismaning@freenet.de) (TLSv1:AES256-SHA:256) (port 25) (Exim 4.72 #3) id 1Q7ahT-0001Mu-CC; Wed, 06 Apr 2011 23:55:43 +0200 Message-ID: <4D9D2645.9000000@freenet.de> Date: Wed, 06 Apr 2011 21:55:00 -0000 From: "h.becker" User-Agent: Mozilla-Thunderbird 2.0.0.9 (X11/20080110) MIME-Version: 1.0 To: Kai Tietz CC: Binutils , Nick Clifton Subject: Re: [patch bfd]: Prevent possible buffer overflow on pdata-section sorting References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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/msg00069.txt.bz2 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 >