From: Mark Wielaard <mjw@redhat.com>
To: elfutils-devel@lists.fedorahosted.org
Subject: [PATCH] libdwfl: Check relocations don't overlap ELF ehdr, shdrs or phdrs.
Date: Sat, 29 Nov 2014 20:40:58 +0100 [thread overview]
Message-ID: <1417290058-24071-1-git-send-email-mjw@redhat.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 4308 bytes --]
American Fuzzy Lop (afl-fuzz) has an habit of generating ELF files
with relocations that when applied (or removed/cleared) change one
of the in-memory ELF headers. There does not seem to be a valid reason
for having section data that contain relocations or to which relocations
are applied to overlap with one of the headers.
If either the section that needs the relocation applied, or the
section that the relocations come from overlap one of the ehdrs,
shdrs or phdrs data then refuse to do the relocations. We update
both section data. It isn't illegal for ELF section data to overlap
the header data, but updating the (relocation) data might corrupt
the in-memory libelf headers causing strange corruptions or errors.
Also check offset + size of a relocation doesn't overflow.
Signed-off-by: Mark Wielaard <mjw@redhat.com>
---
libdwfl/ChangeLog | 6 ++++++
libdwfl/relocate.c | 47 ++++++++++++++++++++++++++++++++++++++++++++++-
2 files changed, 52 insertions(+), 1 deletion(-)
diff --git a/libdwfl/ChangeLog b/libdwfl/ChangeLog
index 5876fcc..03faecf 100644
--- a/libdwfl/ChangeLog
+++ b/libdwfl/ChangeLog
@@ -1,3 +1,9 @@
+2014-11-29 Mark Wielaard <mjw@redhat.com>
+
+ * relocate.c (relocate_section): Check relocation section and target
+ section data don't overlap any of the ELF headers.
+ (relocate): Check for offset + size overflow.
+
2014-11-22 Mark Wielaard <mjw@redhat.com>
* link_map.c (consider_executable): Use elf_getphdrnum.
diff --git a/libdwfl/relocate.c b/libdwfl/relocate.c
index 52b7b5e..4fc0956 100644
--- a/libdwfl/relocate.c
+++ b/libdwfl/relocate.c
@@ -297,6 +297,51 @@ relocate_section (Dwfl_Module *mod, Elf *relocated, const GElf_Ehdr *ehdr,
if (tdata == NULL)
return DWFL_E_LIBELF;
+ /* If either the section that needs the relocation applied, or the
+ section that the relocations come from overlap one of the ehdrs,
+ shdrs or phdrs data then we refuse to do the relocations. It
+ isn't illegal for ELF section data to overlap the header data,
+ but updating the (relocation) data might corrupt the in-memory
+ libelf headers causing strange corruptions or errors. */
+ if (unlikely (shdr->sh_offset < ehdr->e_ehsize
+ || tshdr->sh_offset < ehdr->e_ehsize))
+ return DWFL_E_BADELF;
+
+ GElf_Off shdr_start = ehdr->e_shoff;
+ size_t shnums;
+ if (elf_getshdrnum (relocated, &shnums) < 0)
+ return DWFL_E_LIBELF;
+ /* Overflows will have been checked by elf_getshdrnum/get|rawdata. */
+ GElf_Off shdr_end = shdr_start + shnums * ehdr->e_shentsize;
+ if (unlikely ((shdr->sh_offset >= shdr_start
+ && shdr->sh_offset < shdr_end)
+ || (shdr->sh_offset + shdr->sh_size >= shdr_start
+ && shdr->sh_offset + shdr->sh_size < shdr_end)
+ || (tshdr->sh_offset >= shdr_start
+ && tshdr->sh_offset < shdr_end)
+ || (tshdr->sh_offset + tshdr->sh_size >= shdr_start
+ && tshdr->sh_offset + tshdr->sh_size < shdr_end)))
+ return DWFL_E_BADELF;
+
+ GElf_Off phdr_start = ehdr->e_phoff;
+ size_t phnums;
+ if (elf_getphdrnum (relocated, &phnums) < 0)
+ return DWFL_E_LIBELF;
+ if (phdr_start != 0 && phnums != 0)
+ {
+ /* Overflows will have been checked by elf_getphdrnum/get|rawdata. */
+ GElf_Off phdr_end = phdr_start + phnums * ehdr->e_phentsize;
+ if (unlikely ((shdr->sh_offset >= phdr_start
+ && shdr->sh_offset < phdr_end)
+ || (shdr->sh_offset + shdr->sh_size >= phdr_start
+ && shdr->sh_offset + shdr->sh_size < phdr_end)
+ || (tshdr->sh_offset >= phdr_start
+ && tshdr->sh_offset < phdr_end)
+ || (tshdr->sh_offset + tshdr->sh_size >= phdr_start
+ && tshdr->sh_offset + tshdr->sh_size < phdr_end)))
+ return DWFL_E_BADELF;
+ }
+
/* Apply one relocation. Returns true for any invalid data. */
Dwfl_Error relocate (GElf_Addr offset, const GElf_Sxword *addend,
int rtype, int symndx)
@@ -365,7 +410,7 @@ relocate_section (Dwfl_Module *mod, Elf *relocated, const GElf_Ehdr *ehdr,
return DWFL_E_BADRELTYPE;
}
- if (offset + size > tdata->d_size)
+ if (offset > tdata->d_size || tdata->d_size - offset < size)
return DWFL_E_BADRELOFF;
#define DO_TYPE(NAME, Name) GElf_##Name Name;
--
1.9.3
next reply other threads:[~2014-11-29 19:40 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-29 19:40 Mark Wielaard [this message]
2014-11-30 20:02 Mark Wielaard
2014-12-04 13:46 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=1417290058-24071-1-git-send-email-mjw@redhat.com \
--to=mjw@redhat.com \
--cc=elfutils-devel@lists.fedorahosted.org \
/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).