summaryrefslogtreecommitdiffstats
path: root/lib/iomap.c
diff options
context:
space:
mode:
authorJames Bottomley <James.Bottomley@SteelEye.com>2007-03-16 13:38:35 -0800
committerLinus Torvalds <torvalds@woody.linux-foundation.org>2007-03-16 19:25:06 -0700
commitd1cabd63262707ad5d6bb730f25b7a2852734595 (patch)
treee62f7b1ecbc9dd9b37a50f57ac9136460e9019eb /lib/iomap.c
parente29e175b0f40cffc86068156733def14a7a533ab (diff)
downloadop-kernel-dev-d1cabd63262707ad5d6bb730f25b7a2852734595.zip
op-kernel-dev-d1cabd63262707ad5d6bb730f25b7a2852734595.tar.gz
[PATCH] fix process crash caused by randomisation and 64k pages
This bug was seen on ppc64, but it could have occurred on any architecture with a page size of 64k or above. The problem is that in fs/binfmt_elf.c:randomize_stack_top() randomizes the stack to within 0x7ff pages. On 4k page machines, this is 8MB; on 64k page boxes, this is 128MB. The problem is that the new binary layout (selected in arch_pick_mmap_layout) places the mapping segment 128MB or the stack rlimit away from the top of the process memory, whichever is larger. If you chose an rlimit of less than 128MB (most defaults are in the 8Mb range) then you can end up having your entire stack randomized away. The fix is to make randomize_stack_top() only steal at most 8MB, which this patch does. However, I have to point out that even with this, your stack rlimit might not be exactly what you get if it's > 128MB, because you're still losing the random offset of up to 8MB. The true fix should be to leave an explicit gap for the randomization plus a buffer when determining mmap_base, but that would involve fixing all the architectures. Cc: Arjan van de Ven <arjan@infradead.org> Cc: Ingo Molnar <mingo@elte.hu> Cc: Andi Kleen <ak@suse.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'lib/iomap.c')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud