From: Andrea Arcangeli <aarcange@redhat.com>
To: Andrew Morton <akpm@linux-foundation.org>, linux-mm@kvack.org
Cc: Mike Rapoport <rppt@linux.vnet.ibm.com>,
"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
Mike Kravetz <mike.kravetz@oracle.com>
Subject: [PATCH 1/1] userfaultfd: hugetlbfs: prevent UFFDIO_COPY to fill beyond the end of i_size
Date: Tue, 17 Oct 2017 00:39:14 +0200 [thread overview]
Message-ID: <20171016223914.2421-2-aarcange@redhat.com> (raw)
In-Reply-To: <20171016223914.2421-1-aarcange@redhat.com>
kernel BUG at fs/hugetlbfs/inode.c:484!
RIP: 0010:[<ffffffff815f8520>] [<ffffffff815f8520>] remove_inode_hugepages+0x3d0/0x410
Call Trace:
[<ffffffff815f95b9>] hugetlbfs_setattr+0xd9/0x130
[<ffffffff81526312>] notify_change+0x292/0x410
[<ffffffff816cc6b6>] ? security_inode_need_killpriv+0x16/0x20
[<ffffffff81503c65>] do_truncate+0x65/0xa0
[<ffffffff81504035>] ? do_sys_ftruncate.constprop.3+0xe5/0x180
[<ffffffff8150406a>] do_sys_ftruncate.constprop.3+0x11a/0x180
[<ffffffff8150410e>] SyS_ftruncate+0xe/0x10
[<ffffffff81999f27>] tracesys+0xd9/0xde
This oops was caused by the lack of i_size check in
hugetlb_mcopy_atomic_pte. mmap() can still succeed beyond the end of
the i_size after vmtruncate zapped vmas in those ranges, but the
faults must not succeed, and that includes UFFDIO_COPY.
We could differentiate the retval to userland to represent a SIGBUS
like a page fault would do (vs SIGSEGV), but it doesn't seem very
useful and we'd need to pick a random retval as there's no meaningful
syscall retval that would differentiate from SIGSEGV and SIGBUS,
there's just -EFAULT.
Reviewed-by: Mike Kravetz <mike.kravetz@oracle.com>
Signed-off-by: Andrea Arcangeli <aarcange@redhat.com>
---
mm/hugetlb.c | 32 ++++++++++++++++++++++++++++++--
1 file changed, 30 insertions(+), 2 deletions(-)
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 357161bd1519..0cbb7c37dc33 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -4012,6 +4012,9 @@ int hugetlb_mcopy_atomic_pte(struct mm_struct *dst_mm,
unsigned long src_addr,
struct page **pagep)
{
+ struct address_space *mapping;
+ pgoff_t idx;
+ unsigned long size;
int vm_shared = dst_vma->vm_flags & VM_SHARED;
struct hstate *h = hstate_vma(dst_vma);
pte_t _dst_pte;
@@ -4049,13 +4052,24 @@ int hugetlb_mcopy_atomic_pte(struct mm_struct *dst_mm,
__SetPageUptodate(page);
__set_page_huge_active(page);
+ mapping = dst_vma->vm_file->f_mapping;
+ idx = vma_hugecache_offset(h, dst_vma, dst_addr);
+
/*
* If shared, add to page cache
*/
if (vm_shared) {
- struct address_space *mapping = dst_vma->vm_file->f_mapping;
- pgoff_t idx = vma_hugecache_offset(h, dst_vma, dst_addr);
+ size = i_size_read(mapping->host) >> huge_page_shift(h);
+ ret = -EFAULT;
+ if (idx >= size)
+ goto out_release_nounlock;
+ /*
+ * Serialization between remove_inode_hugepages() and
+ * huge_add_to_page_cache() below happens through the
+ * hugetlb_fault_mutex_table that here must be hold by
+ * the caller.
+ */
ret = huge_add_to_page_cache(page, mapping, idx);
if (ret)
goto out_release_nounlock;
@@ -4064,6 +4078,20 @@ int hugetlb_mcopy_atomic_pte(struct mm_struct *dst_mm,
ptl = huge_pte_lockptr(h, dst_mm, dst_pte);
spin_lock(ptl);
+ /*
+ * Recheck the i_size after holding PT lock to make sure not
+ * to leave any page mapped (as page_mapped()) beyond the end
+ * of the i_size (remove_inode_hugepages() is strict about
+ * enforcing that). If we bail out here, we'll also leave a
+ * page in the radix tree in the vm_shared case beyond the end
+ * of the i_size, but remove_inode_hugepages() will take care
+ * of it as soon as we drop the hugetlb_fault_mutex_table.
+ */
+ size = i_size_read(mapping->host) >> huge_page_shift(h);
+ ret = -EFAULT;
+ if (idx >= size)
+ goto out_release_unlock;
+
ret = -EEXIST;
if (!huge_pte_none(huge_ptep_get(dst_pte)))
goto out_release_unlock;
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2017-10-16 22:39 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-16 22:39 [PATCH 0/1] hugetlbfs: prevent UFFDIO_COPY to fill beyond the end of i_size Andrea Arcangeli
2017-10-16 22:39 ` Andrea Arcangeli [this message]
2017-10-16 23:14 ` [PATCH 1/1] userfaultfd: " Andrew Morton
2017-10-18 19:10 ` Andrea Arcangeli
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=20171016223914.2421-2-aarcange@redhat.com \
--to=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=dgilbert@redhat.com \
--cc=linux-mm@kvack.org \
--cc=mike.kravetz@oracle.com \
--cc=rppt@linux.vnet.ibm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).