Messages in this thread | | | Date | Wed, 1 Sep 2004 19:03:52 +0100 | From | Matthew Wilcox <> | Subject | Re: page fault scalability patch final : i386 tested, x86_64 support added |
| |
On Fri, Aug 27, 2004 at 10:39:54PM -0700, Andrew Morton wrote: > And we need larger atomic types _anyway_ for page->_count. An unprivileged > app can mmap the same page 4G times and can then munmap it once. Do it on > purpose and it's a security hole. Due it by accident and it's a crash.
Sure, but the same kind of app can also do this on 32-bit architectures. Assuming there's only 2.5GB of address space available per process, you'd need 1638 cooperating processes to do it. OK, that's a lot but the lowest limit I can spy on a quick poll of multiuser boxes I have a login on is 3064. Most are above 10,000 (poll sample includes Debian, RHAS and Fedora).
I think it would be better to check for overflow of the atomic_t (atomic_t is signed) in the mmap routines. Then kill the process that caused the overflow. OK, this is a local denial-of-service if someone does it to glibc, but at least the admin should be able to reboot the box.
-- "Next the statesmen will invent cheap lies, putting the blame upon the nation that is attacked, and every man will be glad of those conscience-soothing falsities, and will diligently study them, and refuse to examine any refutations of them; and thus he will by and by convince himself that the war is just, and will thank God for the better sleep he enjoys after this process of grotesque self-deception." -- Mark Twain - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |