This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: avoid crashing after mapping past EOF of invalid shared object

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]