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
next prev parent 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).