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-next>] [day] [month] [year] [list]
Date:	Fri, 6 Jun 2014 13:36:54 -0400
From:	Josh Boyer <jwboyer@...oraproject.org>
To:	Naoya Horiguchi <n-horiguchi@...jp.nec.com>
Cc:	Sasha Levin <sasha.levin@...cle.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	torvalds@...ux-foundation.org, linux-kernel@...r.kernel.org
Subject: pte_present check on hugetlb_entry fix for 3.15?

Hi Naoya,

I noticed that your
mm-add-pte_present-check-on-existing-hugetlb_entry-callbacks.patch in
Andrew's -mm tree has been queued for a while and has a CC to stable on
it.  Is that something that should get into 3.15?  I know it doesn't
cleanly apply to Linus' current tree because of the patch before it, but
it seems to be a fairly independent fix.

This originally came up in this thread: https://lkml.org/lkml/2014/3/18/784
as a fix for some issues Sasha was hitting with the generic page walker
changes, but you found it was an existing issue.  We now have a CVE
assigned for this:

http://seclists.org/oss-sec/2014/q2/399

So I'm wondering if you think this should fix the issue and if it should
go into 3.15.  A backported version is below.  I poked Linus about this
early today privately (my fault, apologies) and he had some
questions/comments on the code.

josh

>From ecc894926ef62080c2a4c4286eccce9d2f30f05a Mon Sep 17 00:00:00 2001
From: Naoya Horiguchi <n-horiguchi@...jp.nec.com>
Date: Fri, 6 Jun 2014 10:00:01 -0400
Subject: [PATCH] mm: add !pte_present() check on existing hugetlb_entry
 callbacks

Page table walker doesn't check non-present hugetlb entry in common path,
so hugetlb_entry() callbacks must check it. The reason for this behavior
is that some callers want to handle it in its own way.

However, some callers don't check it now, which causes unpredictable
result, for example when we have a race between migrating hugepage and
reading /proc/pid/numa_maps. This patch fixes it by adding !pte_present
checks on buggy callbacks.

This bug exists for years and got visible by introducing hugepage migration.

ChangeLog v2:
- fix if condition (check !pte_present() instead of pte_present())

Reported-by: Sasha Levin <sasha.levin@...cle.com>
Signed-off-by: Naoya Horiguchi <n-horiguchi@...jp.nec.com>
Cc: Rik van Riel <riel@...hat.com>
Cc: <stable@...r.kernel.org> [3.12+]
Signed-off-by: Andrew Morton <akpm@...ux-foundation.org>

[ Backported to 3.15.  Signed-off-by: Josh Boyer <jwboyer@...oraproject.org> ]
---
 fs/proc/task_mmu.c | 3 +++
 mm/mempolicy.c     | 6 +++++-
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
index 442177b1119a..89620cdb57c9 100644
--- a/fs/proc/task_mmu.c
+++ b/fs/proc/task_mmu.c
@@ -1354,6 +1354,9 @@ static int gather_hugetbl_stats(pte_t *pte, unsigned long hmask,
 	if (pte_none(*pte))
 		return 0;
 
+	if (!pte_present(*pte))
+		return 0;
+
 	page = pte_page(*pte);
 	if (!page)
 		return 0;
diff --git a/mm/mempolicy.c b/mm/mempolicy.c
index 78e1472933ea..30cc47f8ffa0 100644
--- a/mm/mempolicy.c
+++ b/mm/mempolicy.c
@@ -526,9 +526,13 @@ static void queue_pages_hugetlb_pmd_range(struct vm_area_struct *vma,
 	int nid;
 	struct page *page;
 	spinlock_t *ptl;
+	pte_t entry;
 
 	ptl = huge_pte_lock(hstate_vma(vma), vma->vm_mm, (pte_t *)pmd);
-	page = pte_page(huge_ptep_get((pte_t *)pmd));
+	entry = huge_ptep_get((pte_t *)pmd);
+	if (!pte_present(entry))
+		goto unlock;
+	page = pte_page(entry);
 	nid = page_to_nid(page);
 	if (node_isset(nid, *nodes) == !!(flags & MPOL_MF_INVERT))
 		goto unlock;
-- 
1.9.3

--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ