[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <b040c32a0701291032o431dce63xfc804dc7f9280ff2@mail.gmail.com>
Date: Mon, 29 Jan 2007 10:32:39 -0800
From: "Ken Chen" <kenchen@...gle.com>
To: "Hugh Dickins" <hugh@...itas.com>
Cc: "Adam Litke" <agl@...ibm.com>, "Andrew Morton" <akpm@...l.org>,
"William Irwin" <wli@...omorphy.com>,
"David Gibson" <david@...son.dropbear.id.au>, linux-mm@...ck.org,
linux-kernel@...r.kernel.org, tony.luck@...el.com
Subject: Re: [PATCH] Don't allow the stack to grow into hugetlb reserved regions
On 1/29/07, Hugh Dickins <hugh@...itas.com> wrote:
> But, never mind hugetlb, you still not quite convinced me that there's
> no problem at all with get_user_pages find_extend_vma growing on ia64.
>
> I repeat that ia64_do_page_fault has REGION tests to guard against
> expanding either kind of stack across into another region. ia64_brk,
> ia64_mmap_check and arch_get_unmapped_area have RGN_MAP_LIMIT checks.
> But where is the equivalent paranoia when ptrace calls get_user_pages
> calls find_extend_vma?
>
> If your usual stacks face each other across the same region, they're
> not going to pose problem. But what if someone mmaps MAP_GROWSDOWN
> near the base of a region, then uses ptrace to touch an address near
> the top of the region below?
OK, now I fully understand what you are after. I kept on thinking in the
context of hugetlb. You are correct that ia64 does not have proper address
check for find_extend_vma() and it is indeed a potentially very bad bug in
there. I'm with you, I don't see the equivalent RGN_MAP_LIMIT check in the
get_user_pages() path.
Forwarding this to Tony as I don't have any access to ia64 machine anymore
to test/validate a fix.
- Ken
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists