This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Avoid mapping past end of shared object (BZ #18685)
- From: Florian Weimer <fweimer at redhat dot com>
- To: Siddhesh Poyarekar <siddhesh at redhat dot com>
- Cc: libc-alpha at sourceware dot org, roland at hack dot frob dot com
- Date: Fri, 17 Jul 2015 13:24:05 +0200
- Subject: Re: [PATCH] Avoid mapping past end of shared object (BZ #18685)
- Authentication-results: sourceware.org; auth=none
- References: <1437033625-13561-1-git-send-email-siddhesh at redhat dot com> <55A8928D dot 2090409 at redhat dot com> <20150717061558 dot GD19592 at spoyarek dot pnq dot redhat dot com>
On 07/17/2015 08:15 AM, Siddhesh Poyarekar wrote:
> On Fri, Jul 17, 2015 at 07:28:45AM +0200, Florian Weimer wrote:
>> Can you show the ldd output with this patch applied on some files which
>> crashed before? Is it useful at all?
>
> I'll have to build one since I can't find any from a brief look
> through files I have on my system. The examples were mostly the
> .debug files IIRC, so that has more to do with not crashing than
> actually providing any useful information.
Useful information would be that's a debuginfo file. Showing no output
or garbage is hardly more helpful than crashing because the user still
doesn't know what's wrong. They won't even report a bug, so we can't
help them.
>> Is there a way that an ELF file is corrupted in this way, but can be
>> still be loaded correctly? I wonder if this change will break currently
>> working programs. I do think we need to support loading corrupted ELF
>> files indefinitely if there ever was a binutils version producing them.
>
> I don't know of any valid ELF programs that broke due to this. The
> patch (AFAICT) has been in Fedora for about 3 years, so if something
> had to break, it should have been known by now.
Unfortunately, Fedora coverage for non-i386/x86_64 and proprietary
legacy applications is quite poor.
In this check,
+ if (__glibc_unlikely (ph->p_offset + ph->p_filesz > st.st_size))
do p_offset and p_filesz correspond to the program header values in the
file, or have they already been modified?.
Looking at the unmodified program header values (as reported by elfutils
and the gelf_getphdr function) in a fairly large set of RPMs, I do not
see production ELF files (as opposed debuginfo files or firmware images)
where this constraint is violated (for type 1 headers, that is). The
RPMs are from every minor Red Hat Enterprise Linux release going back to
version 4 and from recent Fedora releases. It's not a complete set of
everything shipped by Red Hat or Fedora by a long shot, but it strongly
suggests that we did not have a recent bug introducing systematic
corruption.
One more question, regarding the new check: Is there already a check
that the addition does not overflow?
--
Florian Weimer / Red Hat Product Security