[Bug ld/24055] _bfd_xcoff_swap_aux_in smashes the stack

[wolfgang.thaller at gmx dot net]

https://sourceware.org/bugzilla/show_bug.cgi?id=24055

--- Comment #6 from Wolfgang Thaller <wolfgang.thaller at gmx dot net> ---
So... here are my findings...

The code handling multiple aux entries was introduced on 1999-05-10 to handle
an undocumented feature of Microsoft's PE format:

1999-05-10  DJ Delorie  <address@hidden>

        [...]
        * coffgen.c (coff_get_normalized_symtab): Properly read long MS
        filename symbols, which use one *or more* auxents.
        * coffswap.h (coff_swap_aux_in): ditto


Neither current MSVC nor binutils generates files that use this feature.

This code later got copied to coff-rs6000, but it was never appropriate for
XCOFF, where multiple aux entries on a C_FILE have a different meaning.

I therefore resubmit my original patch, but it should probably not be copied to
other implementations of swap_aux_in without further discussion.

The existing PE code might still crash for some input files, but I don't know
if they exist in practice.

----

AUX Format

All(?) COFF variants have in common that C_FILE symbols should have a name of
".file", with the actual file name stored in an aux entry. Apparently,
Microsoft once used several consecutive entries to store names that don't fit
into a single aux entry. Microsoft's documentation does not mention that
possibility:

https://docs.microsoft.com/en-us/windows/desktop/debug/pe-format#auxiliary-format-4-files

XCOFF and some other COFF variants handle long file names by storing four zero
bytes followed by a string table offset in the aux entry.

XCOFF defines another field, x_ftype, in those AUX entries that define
the type of the string - so we can have a C_FILE that has a file name,
a time stamp and a compiler version string:

https://www.ibm.com/support/knowledgecenter/ssw_aix_71/com.ibm.aix.files/XCOFF.htm#XCOFF__c0f91aa357jbau

Binutils ignores the x_ftype field and resets it on output; this is also a bug,
though a very low-priority one.

-----

Call Sites

Many call sites are never invoked for C_FILE symbols and are thus not relevant.

coffgen.c:1709

Allocates enough space (contiguous array of internal auxentries, sized to match
the input), and handles filenames spread over multiple aux entries when
handling PE files. This is DJ Delorie's original hack.
It still loops over all aux entries, so it will work with XCOFF-style multiple
aux entries provided my patch. If the multi-aux behaviour is changed for PECOFF
as well, this will need to be changed.

cofflink.c:1761

Only allocates a single internal aux entry and loops over all external aux
entries.
Will crash if there are still COFF (not XCOFF) files with a filename spread
over three or more aux entries (> 36 characters; 3 * 18 bytes will not fit in
sizeof(internal_auxent)).

xcofflink.c:4991

Only allocates one internal aux entry and loops over all external aux entries.

gdb/coffread.c and gdb/xcoffread.c also contain several calls to
bfd_coff_swap_aux_in.
At first glance, none of them allocates extra memory. Danger of crashes here,
as well.

-- 
You are receiving this mail because:
You are on the CC list for the bug.