public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: "Maciej W. Rozycki" <macro@orcam.me.uk>
To: Alan Modra <amodra@gmail.com>
Cc: Chenghua Xu <paul.hua.gm@gmail.com>, binutils@sourceware.org
Subject: Re: PR28306, segfault in _bfd_mips_elf_reloc_unshuffle
Date: Fri, 10 Sep 2021 11:50:04 +0200 (CEST)	[thread overview]
Message-ID: <alpine.DEB.2.21.2109101140250.38640@angie.orcam.me.uk> (raw)
In-Reply-To: <YTsW4HOZ8dc9hMvD@squeak.grove.modra.org>

On Fri, 10 Sep 2021, Alan Modra wrote:

> > I don't think there is any easy and safe way of doing that.  Even
> > though there is a nice tidy array of NULL terminated arelent pointers,
> > the special_function doesn't see an arelent** but rather an arelent*.
> > 
> > Hmm, how about replacing !relocatable above with
> > !(relocatable && !reloc_entry->howto->partial_inplace) ie. the
> > condition under which _bfd_mips_elf_generic_reloc writes section
> > contents?
> 
> Testing revealed some fails
> mipsisa32r2el-elf  +FAIL: MIPS reloc against local symbol overflow
> mipstx39-elf  +FAIL: MIPS reloc against local symbol overflow
> 
> The test in question puts a ".half" at the end of a section, with
> resultant R_MIPS_16, a 4 byte relocation, 2 bytes before the end of
> the section.  I think the test should fail on these targets.  With a
> very carefully crafted testcase it should be possible to cause a gas
> buffer overflow.

 Hmm, it looks to me like a bug in the implementation of the `.half' 
pseudo-op (that it emits a 16-bit rather than a 32-bit data quantity with 
R_MIPS_16 attached to the least significant halfword), but I'm not sure if 
at this time of MIPS target's history it is safe to fix it.  I'll have to 
chew it over a bit and I'll be travelling over the next couple of days 
anyway, so I'll get back to this discussion after the weekend (including 
the issue of `arelent*' vs `arelent**').

  Maciej

  reply	other threads:[~2021-09-10  9:50 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-08 11:00 Alan Modra
2021-09-09  9:51 ` Maciej W. Rozycki
2021-09-09 14:14   ` Alan Modra
2021-09-10  8:27     ` Alan Modra
2021-09-10  9:50       ` Maciej W. Rozycki [this message]
2021-09-10 11:01         ` Alan Modra
2022-12-09 11:08 Alan Modra

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=alpine.DEB.2.21.2109101140250.38640@angie.orcam.me.uk \
    --to=macro@orcam.me.uk \
    --cc=amodra@gmail.com \
    --cc=binutils@sourceware.org \
    --cc=paul.hua.gm@gmail.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).