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. _______________________________________________ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
