linux-kernel - Re: [BUG] rmap: fix page_address_in_vma() to walk through anon_vma

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4BD0688A.7050806@redhat.com>
Date:	Thu, 22 Apr 2010 11:17:30 -0400
From:	Rik van Riel <riel@...hat.com>
To:	Naoya Horiguchi <n-horiguchi@...jp.nec.com>
CC:	linux-mm <linux-mm@...ck.org>, LKML <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Andi Kleen <andi@...stfloor.org>
Subject: Re: [BUG] rmap: fix page_address_in_vma() to walk through anon_vma_chain

On 04/22/2010 01:42 AM, Naoya Horiguchi wrote:
> I found a bug on page_address_in_vma() related to anon_vma_chain.
>
> I wrote a patch, but according to a comment in include/linux/rmap.h,
> I suspect this doesn't meet lock requirement of anon_vma_chain
> (mmap_sem and page_table_lock, see below).
>
>                             mmap_sem      page_table_lock
>    mm/ksm.c:
>      write_protect_page()   hold          not hold
>      replace_page()         hold          not hold
>    mm/memory-failure.c:
>      add_to_kill()          not hold      hold
>    mm/mempolicy.c:
>      new_vma_page()         hold          not hold
>    mm/swapfile.c:
>      unuse_vma()            hold          not hold
>
> Any comments?

Good catch.

However, for anonymous pages, page_address_in_vma only
ever determined whether the page _could_ be part of the
VMA, never whether it actually was.

The function page_address_in_vma has always given
false positives, which means all of the callers already
check that the page is actually part of the process.

This means we may be able to get away with not verifying
the anon_vma at all.  After all, verifying that the VMA
has the anon_vma mapped does not mean the VMA has this
page...

Doing away with that check gets rid of your locking
conundrum :)

Opinions?
--
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/