Specifically you can run the exploit program (just does an mmap and
munmap for each 4MB page in the process VMA) and hit Shift-Scrollock
and watch the free pages fluctuate (the process uses 783 GFP_KERNEL
pages, even though it's called munmap for every mapping).
The problem is this:
mmap simply sets up a number of page table entries to alias a chunk
of memory to a file/device/etc. When munmap is called, it calls
zap_page_range on the mmap. The problem is that when zap_page_range
is called, the pgd for that segment is not unallocated once it becomes
unused. So, you have a superfluous, unused pgd for each 4MB chunk
in the 3GB VMA of the process. I've tried hacking zap_page_range
and munmap to free the pgd, but all I succeed in doing is getting
a real fast reboot when init starts ;(
I don't know enough about the mm in the kernel, but the parts I
looked at (for x86) haven't changed much from 2.0 to 2.1, and this
DoS is easy pickings for jerkwads. The pgd *should* be freed.
The problem is especially bad for programs that run for a long time.
It is possible for several megabytes (max 3MB) of pgds to get leaked
during program execution, and this is GFP_KERNEL memory...unswappable.
Were talking about serious use of unswappable memory, which can cause
Bad Things(tm) for processes that do A LOT of mmaps (think Squid,
Apache, MySQL, etc).
--Perry
-- Perry Harrington Linux rules all OSes. APSoft () email: perry@apsoft.com Think Blue. /\- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu