[PATCH] PR32870: ld: arm32: fix segfault when linking with LLVMgold.so plugin under LTO

[Alan Modra]

On Tue, Jun 03, 2025 at 04:58:36PM +0100, Richard Earnshaw wrote:
> On 15/04/2025 10:14, dongjianqiang (A) wrote:
> > Hi,
> > 
> > Proposed patch to PR32870.
> > When handling the iplt in ARM32, the ld must check whether the input_bfd
> > is in ELF format. If the input is an LLVM Bitcode file, an error will be raised.
> > 
> > Any suggestions? Thanks.
> > 
> > ---
> > 	PR 32870
> > 	* elf32-arm.c (elf32_arm_output_arch_local_syms): Check input_bfd
> > 
> > diff --git a/bfd/elf32-arm.c b/bfd/elf32-arm.c
> > index 3b7cee3de1c..3af964ce034 100644
> > --- a/bfd/elf32-arm.c
> > +++ b/bfd/elf32-arm.c
> > @@ -18345,6 +18345,9 @@ elf32_arm_output_arch_local_syms (bfd *output_bfd,
> >   	  struct arm_local_iplt_info **local_iplt;
> >   	  unsigned int i, num_syms;
> > +	  if (!is_arm_elf (input_bfd))
> > +	    continue;
> > +
> >   	  local_iplt = elf32_arm_local_iplt (input_bfd);
> >   	  if (local_iplt != NULL)
> >   	    {
> 
> I'd like Alan's opinion on this one.  To me it's strange that something that
> is not remotely like a object file is still in the list of input BFDs at
> this point.  This feels like it might be yet another rich source of fuzzing
> bugs.

The patch is OK.

GNU ld can link foreign object files, if they have no relocations or
the relocs are simple enough and the target support for that object
properly describes them in reloc howtos.

> If keeping this in the bfd list is correct, then I think a better fix would
> be to refuse to create a local iplt for this bfd; then we'll simply skip the
> following code because elf32_arm_local_iplt will simply return NULL.

Well, as things stand you need to check the input bfd is the correct
type and thus has elf_arm_obj_tdata before even accessing
elf32_arm_local_iplt.

-- 
Alan Modra