public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Fangrui Song <i@maskray.me>
To: Alan Modra <amodra@gmail.com>, Simon Marchi <simon.marchi@polymtl.ca>
Cc: "H.J. Lu" <hjl.tools@gmail.com>,
	binutils@sourceware.org,  Florian Weimer <fweimer@redhat.com>,
	Kaylee Blake <klkblake@gmail.com>,
	 "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
Subject: Re: [PATCH v4 3/7] bfd: Improve nm and objdump without section header
Date: Wed, 12 Jul 2023 22:34:45 -0700	[thread overview]
Message-ID: <DS7PR12MB576562C386D49DB5CBE122C2CB37A@DS7PR12MB5765.namprd12.prod.outlook.com> (raw)
In-Reply-To: <ZK+FYSeBoHqxk70u@squeak.grove.modra.org>

On Wed, Jul 12, 2023 at 10:02 PM Alan Modra via Binutils
<binutils@sourceware.org> wrote:
>
> On Sun, Jul 09, 2023 at 11:30:01PM -0400, Simon Marchi wrote:
> >
> > > It works for me:
> > >
> > > $ make check TESTS="gdb.base/eu-strip-infcall.exp"
> > > ....
> > > === gdb Summary ===
> > >
> > > # of expected passes 1
> > >
> > > My change only impacts files without section header. eu-strip-infcall.exp does
> > > "eu-strip -f ${binfile}.debug $binfile", which doesn't remove section header.
> > >
> >
> > I can reliably reproduce the problem on two separate machine, one Ubuntu
> > 22.04 and one failrly up to date Arch Linux.  elfutils version 0.186 and
> > 0.189, respectively.
> >
> > It goes wrong when GDB does a bfd_check_format call on
> > testsuite/outputs/gdb.base/eu-strip-infcall/eu-strip-infcall.debug.
> > Before you commit it works, and after your commit it returns false.  It
> > happens in this new statement added to elf_object_p, added by the commit:
> >
> >             if ((i_phdr->p_offset + i_phdr->p_filesz) > filesize)
> >               goto got_no_match;
> >
> > (top-gdb) p i_phdr->p_offset
> > $1 = 8192
> > (top-gdb) p i_phdr->p_filesz
> > $2 = 196
> > (top-gdb) p filesize
> > $3 = 5104
> > (top-gdb) p i
> > $4 = 4
> >
> > It would be this program header causing the condition to fail:
> >
> >   Type           Offset   VirtAddr           PhysAddr           FileSiz  MemSiz   Flg Align
> >   ...
> >   LOAD           0x002000 0x0000000000002000 0x0000000000002000 0x0000c4 0x0000c4 R   0x1000
> >
> > So, the program header of the .debug file describes the segments of the
> > main binary, not sure if that's expected.
>
> No, that's not expected.  Program headers in a .debug file ought to
> describe the contents of the debug file.  You'll typically see many
> with p_filesz zero.  eu-strip appears to be broken in this respect.

Do you have a bug number for eu-strip ? It seems good to keep a
reference of the bug
so that we can track it.

> There is another problem with the code added to elf_object_p:
> _bfd_elf_get_dynamic_symbols is told that it can access up to e_phnum
> program headers, but they very likely haven't all been swapped in.
>
> I'm going to apply the following patch.
> ----
>
> elf_object_p load of dynamic symbols
>
> This fixes an uninitialised memory access on a fuzzed file:
> 0 0xf22e9b in offset_from_vma /src/binutils-gdb/bfd/elf.c:1899:2
> 1 0xf1e90f in _bfd_elf_get_dynamic_symbols /src/binutils-gdb/bfd/elf.c:2099:13
> 2 0x10e6a54 in bfd_elf32_object_p /src/binutils-gdb/bfd/elfcode.h:851:9
>
> Hopefully it will also stop any attempt to load dynamic symbols from
> eu-strip debug files.
>
>         * elfcode.h (elf_object_p): Do not attempt to load dynamic
>         symbols for a file with no section headers until all the
>         program headers are swapped in.  Do not fail on eu-strip debug
>         files.
>
> diff --git a/bfd/elfcode.h b/bfd/elfcode.h
> index aae66bcebf8..b2277921680 100644
> --- a/bfd/elfcode.h
> +++ b/bfd/elfcode.h
> @@ -819,6 +819,7 @@ elf_object_p (bfd *abfd)
>         goto got_no_match;
>        if (bfd_seek (abfd, (file_ptr) i_ehdrp->e_phoff, SEEK_SET) != 0)
>         goto got_no_match;
> +      bool eu_strip_broken_phdrs = false;
>        i_phdr = elf_tdata (abfd)->phdr;
>        for (i = 0; i < i_ehdrp->e_phnum; i++, i_phdr++)
>         {
> @@ -839,21 +840,31 @@ elf_object_p (bfd *abfd)
>                   abfd->read_only = 1;
>                 }
>             }
> -         if (i_phdr->p_filesz != 0)
> -           {
> -             if ((i_phdr->p_offset + i_phdr->p_filesz) > filesize)
> -               goto got_no_match;
> -             /* Try to reconstruct dynamic symbol table from PT_DYNAMIC
> -                segment if there is no section header.  */
> -             if (i_phdr->p_type == PT_DYNAMIC
> -                 && i_ehdrp->e_shstrndx == 0
> -                 && i_ehdrp->e_shoff == 0
> -                 && !_bfd_elf_get_dynamic_symbols (abfd, i_phdr,
> -                                                   elf_tdata (abfd)->phdr,
> -                                                   i_ehdrp->e_phnum,
> -                                                   filesize))
> -               goto got_no_match;
> -           }
> +         /* Detect eu-strip -f debug files, which have program
> +            headers that describe the original file.  */
> +         if (i_phdr->p_filesz != 0
> +             && (i_phdr->p_filesz > filesize
> +                 || i_phdr->p_offset > filesize - i_phdr->p_filesz))
> +           eu_strip_broken_phdrs = true;
> +       }
> +      if (!eu_strip_broken_phdrs
> +         && i_ehdrp->e_shoff == 0
> +         && i_ehdrp->e_shstrndx == 0)
> +       {
> +         /* Try to reconstruct dynamic symbol table from PT_DYNAMIC
> +            segment if there is no section header.  */
> +         i_phdr = elf_tdata (abfd)->phdr;
> +         for (i = 0; i < i_ehdrp->e_phnum; i++, i_phdr++)
> +           if (i_phdr->p_type == PT_DYNAMIC)
> +             {
> +               if (i_phdr->p_filesz != 0
> +                   && !_bfd_elf_get_dynamic_symbols (abfd, i_phdr,
> +                                                     elf_tdata (abfd)->phdr,
> +                                                     i_ehdrp->e_phnum,
> +                                                     filesize))
> +                 goto got_no_match;
> +               break;
> +             }
>         }
>      }
>
>
> --
> Alan Modra
> Australia Development Lab, IBM

  reply	other threads:[~2023-07-13  5:41 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20230606175846.399377-1-hjl.tools@gmail.com>
     [not found] ` <20230606175846.399377-4-hjl.tools@gmail.com>
2023-07-01  2:12   ` Simon Marchi
2023-07-07 15:26     ` H.J. Lu
2023-07-10  3:30       ` Simon Marchi
2023-07-13  5:02         ` Alan Modra
2023-07-13  5:34           ` Fangrui Song [this message]
2023-07-13 21:58           ` Mark Wielaard

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=DS7PR12MB576562C386D49DB5CBE122C2CB37A@DS7PR12MB5765.namprd12.prod.outlook.com \
    --to=i@maskray.me \
    --cc=amodra@gmail.com \
    --cc=binutils@sourceware.org \
    --cc=fweimer@redhat.com \
    --cc=gdb-patches@sourceware.org \
    --cc=hjl.tools@gmail.com \
    --cc=klkblake@gmail.com \
    --cc=simon.marchi@polymtl.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).