This is the mail archive of the
mailing list for the glibc project.
Re: avoid crashing after mapping past EOF of invalid shared object
- From: Roland McGrath <roland at hack dot frob dot com>
- To: Alexandre Oliva <aoliva at redhat dot com>
- Cc: libc-alpha at sources dot redhat dot com
- Date: Fri, 3 Feb 2012 13:45:01 -0800 (PST)
- Subject: Re: avoid crashing after mapping past EOF of invalid shared object
- References: <firstname.lastname@example.org>
Off hand, that doesn't look like it handles the integer overflow case
which could produce the same crash scenario.
I haven't done this in a DSO, but I have used in an executable a PT_LOAD
that's past the end of the file for the purpose of reserving a large
address space during the mapping. But that uses a PT_LOAD without PF_W,
since with PF_W and certain kernel VM overcommit configurations you're
requiring a large amount of swap available to preallocate.
I don't see a likely need to do that kind of trick with a DSO. (With an
executable, you have to do it in the phdrs since that's the only way to
ensure your reserving mapping is made before ASLR puts the vDSO someplace
that fragments your address space so no chunk as large as you wanted is
left.) But the conservative change here would be to refuse it only when it
really is about to lead to a crash. Since literally that would require
doing some more complex bookkeeping and/or calculation, I think a
reasonable compromise is to refuse it for any case with PF_W and memsz>filesz.