Re: [PATCH] Avoid mapping past end of shared object (BZ #18685)

[Siddhesh Poyarekar <siddhesh at redhat dot com>]

On Fri, Jul 17, 2015 at 01:24:05PM +0200, Florian Weimer wrote:
> 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.

The trouble is, you don't know for sure that it is a debuginfo file.
That's where Carlos talked about the need for a new flag.

> Unfortunately, Fedora coverage for non-i386/x86_64 and proprietary
> legacy applications is quite poor.

The patch has been in rhel-6 for a similar amount of time as well,
i.e. since before I started maintaining the tree.

> 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?.

They correspond to the program header values, why do you think they
have 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.

Yes, ELF files (minus debuginfo) build by our assemblers and linkers
should not have this issue.

> One more question, regarding the new check: Is there already a check
> that the addition does not overflow?

There isn't.  I intend to add it but it doesn't seem like there's
agreement on including this patch at all.

Siddhesh