This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH-bfd] i386-mingw32-ld crash on x86_64 linux


On Tue, Apr 14, 2009 at 03:38:40PM +0100, Dave Korn wrote:
> Peter O'Gorman wrote:
> 
> > This patch fixes the crash, though we are still unsure why it crashes
> > with an x86_64 linux build and works with an i386 linux build.
> 
>   Different 32-vs-64 type sizes or memory map layouts, who knows.
> 
> > 2009-04-14  Peter O'Gorman  <pogma@thewrittenword.com>
> > 
> > 	* peXXigen.c: Ensure in->_n._n_name is NULL terminated.
> 
>   This looks wrong, for two reasons:
> 
> 1.  Buffer overflow: this writes one byte past the end of the _n_name array,
> potentially corrupting the n_value field.

Ugh :(

> 
> +    in->_n._n_name[SYMNMLEN] = 0;
> 
> 2.  Disregards the PE specification: from chapter 4 (Section table):
> 
> Offset	Size	Field	Description
>   0	8	Name	An 8-byte, null-padded UTF-8 encoded string. If the string is
> exactly 8 characters long, there is no terminating null. For longer names,
> this field contains a slash (/) that is followed by an ASCII representation of
> a decimal number that is an offset into the string table. Executable images do
> not use a string table and do not support section names longer than 8
> characters. Long names in object files are truncated if they are emitted to an
> executable file.
> 

Later in the same function there is:
if (strcmp (sec->name, in->n_name) == 0)

So that would need to change to strncmp, with luck that is the only
place that expects n_name to be null terminated.

>   I think you probably need to reanalyze what's going on here.  The names
> aren't supposed to be nul-terminated, but we don't know for sure if gdb is
> displaying them correctly; those ones with the trailing \004 are too long to
> fit in the _n_name field, so ought to be stored as long section names in the
> COFF string table.  The other possibility is that GDB has displayed a byte too
> many because it has a bug and expects nul-terminated strings, the \004 being
> the low byte of n_value.  If that turns out to be the case, then the
> .idata$4/.idata$5 section names are actually duplicated, which could possibly
> explain the problem.

Will look into this.

> 
>   Got a simple testcase?

No, it only fails for this one library.

> Are you allowed to share the .o member from the .lib
> file involved?

Afraid not.

Thanks for the reply, was extremely helpful.

Peter
-- 
Peter O'Gorman
pogma@thewrittenword.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]