public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Alan Modra <amodra@gmail.com>
To: Mark Harmstone <mark@harmstone.com>
Cc: binutils@sourceware.org
Subject: Re: [PATCH] Avoid divide by zero when reading invalid PDB archive
Date: Fri, 16 Sep 2022 13:01:49 +0930	[thread overview]
Message-ID: <YyPuJdXjKdNu5My0@squeak.grove.modra.org> (raw)
In-Reply-To: <20220916004034.10189-1-mark@harmstone.com>

On Fri, Sep 16, 2022 at 01:40:34AM +0100, Mark Harmstone wrote:
> As discovered by Alan Modra - see
> https://sourceware.org/pipermail/binutils/2022-September/122878.html.
> 
> ---
>  bfd/pdb.c | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/bfd/pdb.c b/bfd/pdb.c
> index 9a431c23b1f..0ce3bc46ac6 100644
> --- a/bfd/pdb.c
> +++ b/bfd/pdb.c
> @@ -80,6 +80,12 @@ pdb_get_elt_at_index (bfd *abfd, symindex sym_index)
>  
>    block_size = bfd_getl32 (int_buf);
>  
> +  if (block_size == 0)
> +    {
> +      bfd_set_error (bfd_error_malformed_archive);
> +      return NULL;
> +    }
> +

I was looking for a little more than just preventing the divide by
zero.  Based on the doc link at llvm.org, I wrote the following:

  if ((block_size & -block_size) != block_size
      || block_size < 512
      || block_size > 4096)
    {
      bfd_set_error (bfd_error_malformed_archive);
      return NULL;
    }

But then looked further at your code and wondered about all the rest
of the 32-bit values read from file.  For example,
  block_map_addr * block_size might overflow.  (Which leads to the
question of whether you can have pdb files larger than 4G?)

You probably want something like

  file_ptr block_size, where;
  ...
  block_map_addr = bfd_getl32 (int_buf);
  if (_bfd_mul_overflow (block_map_addr, block_size, &where))
    {
      bfd_set_error (bfd_error_malformed_archive);
      return NULL;
    }
  if (bfd_seek (abfd, where, SEEK_SET))
    return NULL;

Using file_ptr for block_size will perform the multiply in the
appropriate size for the host system.

I'll commit the patch I wrote, and leave the rest for you to do at
your leisure.

-- 
Alan Modra
Australia Development Lab, IBM

      reply	other threads:[~2022-09-16  3:31 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-16  0:40 Mark Harmstone
2022-09-16  3:31 ` Alan Modra [this message]

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=YyPuJdXjKdNu5My0@squeak.grove.modra.org \
    --to=amodra@gmail.com \
    --cc=binutils@sourceware.org \
    --cc=mark@harmstone.com \
    /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).