Bug 1069 - Buffer overflow in tc-crx.c
Summary: Buffer overflow in tc-crx.c
Status: RESOLVED FIXED
Alias: None
Product: binutils
Classification: Unclassified
Component: gas (show other bugs)
Version: 2.16
: P2 normal
Target Milestone: ---
Assignee: unassigned
URL:
Keywords:
: 1068 (view as bug list)
Depends on:
Blocks:
 
Reported: 2005-07-14 13:40 UTC by Paul Woegerer
Modified: 2005-07-14 16:46 UTC (History)
2 users (show)

See Also:
Host: i686-pc-linux-gnu
Target: crx-unknown-elf
Build: i686-pc-linux-gnu
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Paul Woegerer 2005-07-14 13:40:57 UTC
The i686-pc-linux-gnu build of the assembler from binutils 2.16 crx-port
creates a segmentation fault with the assembly file below. This time the
problem is located in libiberty/xexit.c where the function pointer named
_xexit_cleanup in line 44 is NOT initialized to NULL.

The following patch for xexit.c (Revision 1.7) fixes this problem:

-------------------------------------------- patch for libiberty/xexit.c

*** xexit.c     2005-07-14 10:19:14.399002000 +0200
--- xexit_fixed.c       2005-07-14 10:37:09.358001000 +0200
***************
*** 41,47 ****

  /* This variable is set by xatexit if it is called.  This way, xmalloc
     doesn't drag xatexit into the link.  */
! void (*_xexit_cleanup) (void);

  void
  xexit (int code)
--- 41,47 ----

  /* This variable is set by xatexit if it is called.  This way, xmalloc
     doesn't drag xatexit into the link.  */
! void (*_xexit_cleanup) (void) = NULL;

  void
  xexit (int code) 

--------------------------------------------- libiberty-xexit-segfault.s 

        .size  
__ZNK1S1fElllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllc,
.-__ZNK1S1fElllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllc
        .section        .text
        .align  4
        .globl  _main
        .type   _main, @function
_main:
        bal     ra,
__ZNK1S1fElllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllc
        .size   _main, .-_main
Comment 1 Alan Modra 2005-07-14 14:34:07 UTC
No, this is a buffer overflow of gas/config/tc-crx.c:ins_parse in reset_vars.
Comment 2 Nick Clifton 2005-07-14 15:36:11 UTC
Subject: Re:  Segmentation fault in libiberty/xexit.c:51

Hi Guys,

> Alan wrote:
> No, this is a buffer overflow of gas/config/tc-crx.c:ins_parse in reset_vars.

And I am applying this patch to stop the overflow and prevent the 
seg-fault.  (This also makes the patch applied for 1063 redundant, but 
that should not matter).

Cheers
   Nick

gas/ChangeLog
2005-07-14  Nick Clifton  <nickc@redhat.com>

	PR 1069
	* config/tc-crx.c (reset_vars): Use strncpy to prevent overflowing
	the ins_parse buffer.

Index: gas/config/tc-crx.c
===================================================================
RCS file: /cvs/src/src/gas/config/tc-crx.c,v
retrieving revision 1.15
diff -c -3 -p -r1.15 tc-crx.c
*** gas/config/tc-crx.c	7 Jun 2005 17:54:16 -0000	1.15
--- gas/config/tc-crx.c	14 Jul 2005 15:33:26 -0000
*************** reset_vars (char *op)
*** 268,274 ****
    memset (& output_opcode, '\0', sizeof (output_opcode));
  
    /* Save a copy of the original OP (used in error messages).  */
!   strcpy (ins_parse, op);
  }
  
  /* This macro decides whether a particular reloc is an entry in a
--- 268,275 ----
    memset (& output_opcode, '\0', sizeof (output_opcode));
  
    /* Save a copy of the original OP (used in error messages).  */
!   strncpy (ins_parse, op, sizeof ins_parse - 1);
!   ins_parse [sizeof ins_parse - 1] = 0;
  }
  
  /* This macro decides whether a particular reloc is an entry in a
Comment 3 Nick Clifton 2005-07-14 15:37:13 UTC
Patch applied
Comment 4 Ian Lance Taylor 2005-07-14 16:46:57 UTC
*** Bug 1068 has been marked as a duplicate of this bug. ***