PR28423, use-after-free in objdump

PR28423, use-after-free in objdump

XCOFF archives use a bi-directional linked list for file members.  So
one member points to both the previous member and the next member.
Members may not be sequentially ordered in the file.  This of course
is over-engineered nonsense and an attractive target for fuzzers.
(There is even a free list of members!)  The testcase in PR28423 is an
XCOFF archive with one member pointing to itself, which results in
lots of bad behaviour.  For example, "ar t" never terminates.

The use-after-free with "objdump -r" happens like this:  The first
archive element is opened, its symbols are read and "canonicalized"
for objdump, then relocations are read and printed.  Those relocations
use the canonicalized symbols, and also happen to be cached by the
coff bfd backend support.  objdump frees the symbols.  The next
archive element is then opened.  This must be done before the first
element is closed, because finding the next element uses data held in
the currect element.  Unfortunately the next element happens to be the
original, so we aren't opening, we're reopening a bfd which has cached
data.  When the relocations are printed they use the cached copy
containing references to the freed canonical symbols.

This patch adds a little sanity checking to the XCOFF "open next
archive file" support, so that it rejects archive members pointing at
themselves.  That is sufficient to cure this problem.  Anything more
is overkill.  If someone deliberately fuzzes an XCOFF archive with an
element loop then reports an "ar" bug when it runs forever, they will
find their bug report closed WONTFIX.

	PR 28423
	* coff-rs6000.c (_bfd_xcoff_read_ar_hdr): Save size occupied
	by member name in areltdata.extra_size.
	(_bfd_xcoff_openr_next_archived_file): Sanity check nextoff.
	* coff64-rs6000.c (xcoff64_openr_next_archived_file): Call
	_bfd_xcoff_openr_next_archived_file.