From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6945 invoked by alias); 30 Jun 2006 12:43:41 -0000 Received: (qmail 6892 invoked by uid 22791); 30 Jun 2006 12:43:40 -0000 X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 30 Jun 2006 12:43:37 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5UChZ3L013148 for ; Fri, 30 Jun 2006 08:43:35 -0400 Received: from pobox.surrey.redhat.com (pobox.surrey.redhat.com [172.16.10.17]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5UChTIf012161 for ; Fri, 30 Jun 2006 08:43:29 -0400 Received: from localhost.localdomain.redhat.com (vpn-68-2.surrey.redhat.com [10.32.68.2]) by pobox.surrey.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5UChRag002288 for ; Fri, 30 Jun 2006 13:43:28 +0100 To: binutils@sourceware.org Subject: [PATCH]: Improve readelf's handling of corrupt call frames From: Nick Clifton Date: Fri, 30 Jun 2006 12:46:00 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-IsSubscribed: yes Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org X-SW-Source: 2006-06/txt/msg00439.txt.bz2 Hi Guys, A coworker recently across a situation where readelf would seg fault whilst trying to display the call frame information for a binary built for a 16-bit target. Whilst the issue of whether the call frame info in this binary was actually corrupt is still in debate (it is a segmented 16/24/32 bit architecture), the fact remains that readelf should not seg fault. So I am going to apply the attached patch. It detects situations where the end of a call frame data block is beyond the end of the .debug_frame section, and it prevents the code that handles corrupt CIE pointers from resetting the start pointer to the end of the block. This causes problems because the code later on will attempt to read the rest of the block's information from beyond the end of the block. Cheers Nick binutils/ChangeLog 2006-06-30 Nick Clifton * dwarf.c (display_debug_frames): Catch a corrupt length field generating an end of block address that is beyond the end of the section. When encountering a corrupt CIE pointer do not reset the start pointer as more data still has to be read. Do not warn about user defined call frame instructions.