All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Liu Shixin <liushixin2@huawei.com>
Cc: Liu Zixian <liuzixian4@huawei.com>,
	Mike Kravetz <mike.kravetz@oracle.com>,
	Muchun Song <songmuchun@bytedance.com>,
	Sidhartha Kumar <sidhartha.kumar@oracle.com>,
	John Hubbard <jhubbard@nvidia.com>,
	"David Hildenbrand" <david@redhat.com>,
	Kefeng Wang <wangkefeng.wang@huawei.com>, <linux-mm@kvack.org>,
	<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v4] mm: hugetlb: fix UAF in hugetlb_handle_userfault
Date: Sun, 25 Sep 2022 11:28:26 -0700	[thread overview]
Message-ID: <20220925112826.c3efd2cf438d1bb6329f78ed@linux-foundation.org> (raw)
In-Reply-To: <20220924034905.2694686-1-liushixin2@huawei.com>

On Sat, 24 Sep 2022 11:49:05 +0800 Liu Shixin <liushixin2@huawei.com> wrote:

> The vma_lock and hugetlb_fault_mutex are dropped before handling
> userfault and reacquire them again after handle_userfault(), but
> reacquire the vma_lock could lead to UAF[1,2] due to the following
> race,
> 
> hugetlb_fault
>   hugetlb_no_page
>     /*unlock vma_lock */
>     hugetlb_handle_userfault
>       handle_userfault
>         /* unlock mm->mmap_lock*/
>                                            vm_mmap_pgoff
>                                              do_mmap
>                                                mmap_region
>                                                  munmap_vma_range
>                                                    /* clean old vma */
>         /* lock vma_lock again  <--- UAF */
>     /* unlock vma_lock */
> 
> Since the vma_lock will unlock immediately after hugetlb_handle_userfault(),
> let's drop the unneeded lock and unlock in hugetlb_handle_userfault() to fix
> the issue.
> 

Thanks.  Turns out that porting all the pending material on top of this
change was not a confidence-inspiring activity.  So I ended up merging
your v3.  Please work with Greg on the backporting when he gets on to
it?  Hopefully that will merely involve sending him this v4.


  reply	other threads:[~2022-09-25 18:28 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-24  3:49 [PATCH v4] mm: hugetlb: fix UAF in hugetlb_handle_userfault Liu Shixin
2022-09-25 18:28 ` Andrew Morton [this message]
2022-09-26  6:48   ` Liu Shixin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220925112826.c3efd2cf438d1bb6329f78ed@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=david@redhat.com \
    --cc=jhubbard@nvidia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=liushixin2@huawei.com \
    --cc=liuzixian4@huawei.com \
    --cc=mike.kravetz@oracle.com \
    --cc=sidhartha.kumar@oracle.com \
    --cc=songmuchun@bytedance.com \
    --cc=wangkefeng.wang@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.