coff: Ignore corrupt relocation table

  Ignore slurp corrupt relocation table to avoid linker crash later.

	PR ld/33455
	* coffcode.h (coff_slurp_reloc_table): Return false for illegal
	symbol index.

Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
---
 bfd/coffcode.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
  

On Fri, Sep 19, 2025 at 7:59 AM H.J. Lu <hjl.tools@gmail.com> wrote:
>
> Ignore slurp corrupt relocation table to avoid linker crash later.
>
>         PR ld/33455
>         * coffcode.h (coff_slurp_reloc_table): Return false for illegal
>         symbol index.
>
> Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
> ---
>  bfd/coffcode.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/bfd/coffcode.h b/bfd/coffcode.h
> index 4a1f4be3773..3dfb31f6b79 100644
> --- a/bfd/coffcode.h
> +++ b/bfd/coffcode.h
> @@ -5306,8 +5306,8 @@ coff_slurp_reloc_table (bfd * abfd, sec_ptr asect, asymbol ** symbols)
>                 /* xgettext:c-format */
>                 (_("%pB: warning: illegal symbol index %ld in relocs"),
>                  abfd, dst.r_symndx);
> -             cache_ptr->sym_ptr_ptr = &bfd_abs_section_ptr->symbol;
> -             ptr = NULL;
> +             /* Ignore corrupt relocation table: PR ld/33455.  */
> +             return false;
>             }
>           else
>             {
> --
> 2.51.0
>

Any comments or objections?
  

On Sun, Sep 21, 2025 at 03:47:11PM +0800, H.J. Lu wrote:
> On Fri, Sep 19, 2025 at 7:59 AM H.J. Lu <hjl.tools@gmail.com> wrote:
> >
> > Ignore slurp corrupt relocation table to avoid linker crash later.
> >
> >         PR ld/33455
> >         * coffcode.h (coff_slurp_reloc_table): Return false for illegal
> >         symbol index.
> >
> > Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
> > ---
> >  bfd/coffcode.h | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/bfd/coffcode.h b/bfd/coffcode.h
> > index 4a1f4be3773..3dfb31f6b79 100644
> > --- a/bfd/coffcode.h
> > +++ b/bfd/coffcode.h
> > @@ -5306,8 +5306,8 @@ coff_slurp_reloc_table (bfd * abfd, sec_ptr asect, asymbol ** symbols)
> >                 /* xgettext:c-format */
> >                 (_("%pB: warning: illegal symbol index %ld in relocs"),
> >                  abfd, dst.r_symndx);
> > -             cache_ptr->sym_ptr_ptr = &bfd_abs_section_ptr->symbol;
> > -             ptr = NULL;
> > +             /* Ignore corrupt relocation table: PR ld/33455.  */
> > +             return false;
> >             }
> >           else
> >             {
> > --
> > 2.51.0
> >
> 
> Any comments or objections?

All three of your patches for these fuzzed object file linker bugs
reduce the capability of the binutils to display corrupted object
files.  I'd rather completely ignore fuzzers than do that.
  

On Sun, Sep 21, 2025 at 6:12 PM Alan Modra <amodra@gmail.com> wrote:
>
> On Sun, Sep 21, 2025 at 03:47:11PM +0800, H.J. Lu wrote:
> > On Fri, Sep 19, 2025 at 7:59 AM H.J. Lu <hjl.tools@gmail.com> wrote:
> > >
> > > Ignore slurp corrupt relocation table to avoid linker crash later.
> > >
> > >         PR ld/33455
> > >         * coffcode.h (coff_slurp_reloc_table): Return false for illegal
> > >         symbol index.
> > >
> > > Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
> > > ---
> > >  bfd/coffcode.h | 4 ++--
> > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/bfd/coffcode.h b/bfd/coffcode.h
> > > index 4a1f4be3773..3dfb31f6b79 100644
> > > --- a/bfd/coffcode.h
> > > +++ b/bfd/coffcode.h
> > > @@ -5306,8 +5306,8 @@ coff_slurp_reloc_table (bfd * abfd, sec_ptr asect, asymbol ** symbols)
> > >                 /* xgettext:c-format */
> > >                 (_("%pB: warning: illegal symbol index %ld in relocs"),
> > >                  abfd, dst.r_symndx);
> > > -             cache_ptr->sym_ptr_ptr = &bfd_abs_section_ptr->symbol;
> > > -             ptr = NULL;
> > > +             /* Ignore corrupt relocation table: PR ld/33455.  */
> > > +             return false;
> > >             }
> > >           else
> > >             {
> > > --
> > > 2.51.0
> > >
> >
> > Any comments or objections?
>
> All three of your patches for these fuzzed object file linker bugs
> reduce the capability of the binutils to display corrupted object

Such information displayed by binutils is unreliable and corrupted
objects may lead to corrupted executable.   I think benefits of
such corrupted information are very limited if any.

> files.  I'd rather completely ignore fuzzers than do that.
>
> --
> Alan Modra
  

On 21.09.2025 13:45, H.J. Lu wrote:
> On Sun, Sep 21, 2025 at 6:12 PM Alan Modra <amodra@gmail.com> wrote:
>> On Sun, Sep 21, 2025 at 03:47:11PM +0800, H.J. Lu wrote:
>>> Any comments or objections?
>>
>> All three of your patches for these fuzzed object file linker bugs
>> reduce the capability of the binutils to display corrupted object
> 
> Such information displayed by binutils is unreliable and corrupted
> objects may lead to corrupted executable.   I think benefits of
> such corrupted information are very limited if any.

I agree with Alan. Corruption or anomalies may be diagnosed (by
warnings, in particular when linking), but we still should aim at
displaying to users whatever we can sensibly display.

Jan
  

On Sun, Sep 21, 2025 at 07:52:01PM +0200, Jan Beulich wrote:
> On 21.09.2025 13:45, H.J. Lu wrote:
> > On Sun, Sep 21, 2025 at 6:12 PM Alan Modra <amodra@gmail.com> wrote:
> >> On Sun, Sep 21, 2025 at 03:47:11PM +0800, H.J. Lu wrote:
> >>> Any comments or objections?
> >>
> >> All three of your patches for these fuzzed object file linker bugs
> >> reduce the capability of the binutils to display corrupted object
> > 
> > Such information displayed by binutils is unreliable and corrupted
> > objects may lead to corrupted executable.   I think benefits of
> > such corrupted information are very limited if any.
> 
> I agree with Alan. Corruption or anomalies may be diagnosed (by
> warnings, in particular when linking), but we still should aim at
> displaying to users whatever we can sensibly display.

Yes, it would be quite OK to refuse to link objects that are
corrupted, but we shouldn't refuse to objdump them.
  

On Mon, Sep 22, 2025 at 6:14 AM Alan Modra <amodra@gmail.com> wrote:
>
> On Sun, Sep 21, 2025 at 07:52:01PM +0200, Jan Beulich wrote:
> > On 21.09.2025 13:45, H.J. Lu wrote:
> > > On Sun, Sep 21, 2025 at 6:12 PM Alan Modra <amodra@gmail.com> wrote:
> > >> On Sun, Sep 21, 2025 at 03:47:11PM +0800, H.J. Lu wrote:
> > >>> Any comments or objections?
> > >>
> > >> All three of your patches for these fuzzed object file linker bugs
> > >> reduce the capability of the binutils to display corrupted object
> > >
> > > Such information displayed by binutils is unreliable and corrupted
> > > objects may lead to corrupted executable.   I think benefits of
> > > such corrupted information are very limited if any.
> >
> > I agree with Alan. Corruption or anomalies may be diagnosed (by
> > warnings, in particular when linking), but we still should aim at
> > displaying to users whatever we can sensibly display.
>
> Yes, it would be quite OK to refuse to link objects that are
> corrupted, but we shouldn't refuse to objdump them.
>

I will see what I can do.