[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 #2 from Wolfgang Thaller <wolfgang.thaller at gmx dot net> ---
Probably won't work for me; I added an assert myself at first and it did in
fact trigger. I am working with an old XCOFF file provided by Apple back in the
90s, and it contains a C_FILE with a total of four aux entries. They are
distinguished by their x_ftype field, and contain the source file name, the
compile time stamp, the compiler version and some "compiler defined
information", respectively.

It does not look malformed to me, though of course Apple's 1990s interpretation
of XCOFF could have diverged from the one that is still relevant today :-)

Also, I am still a bit skeptical.
So you are saying that swap_aux_in is supposed to copy all aux entries into one
internal_auxent structure?

In xcofflink.c:4490, functio xcoff_link_input_bfd, which is where I encountered
the stack smashage, swap_aux_in is invoked in a loop over all n_numaux entries.
Swap in one aux entry, do something, swap out the one aux entry, advance to
next aux entry.
The corresponding swap_aux_out function only copies back one at a time; it does
not somehow extract multiple aux entries out of a single internal_auxent. In
fact, I have not seen any other code that indicates that an iternal_auxent
might correspond to more than one external_auxent.

The code in xcofflink.c makes perfect sense to me under the assumption that
swap_aux_in is supposed to copy only one aux entry, and no sense at all with
the present implementation of swap_aux_in.

The swap_aux_in function as written also leaves the internal_auxent structure
entirely uninitialized if index is not null, which is really scary (and
technically UB as well).

Also, if the string contents of the AUX entry fit within 14 (E_FILNMLEN)
characters, the string is stored inline, otherwise it is stored as a reference
to the string table.
In the string table case, swap_aux_in only copies the pointers for the current
aux entry. The loop that calls it from xcoff_link_input_bfd handles the string
table reference after the call.
If the first aux entry contains an inline string (<= 14 bytes), then all
entries are written into the auxent.

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