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:	Mon, 16 Mar 2015 11:29:45 -0700
From:	Laura Abbott <lauraa@...eaurora.org>
To:	Joonsoo Kim <iamjoonsoo.kim@....com>,
	Vlastimil Babka <vbabka@...e.cz>, Gioh Kim <gioh.kim@....com>
Cc:	Laura Abbott <lauraa@...eaurora.org>, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org,
	Naoya Horiguchi <n-horiguchi@...jp.nec.com>,
	Mel Gorman <mgorman@...e.de>, Rik van Riel <riel@...hat.com>,
	Yasuaki Ishimatsu <isimatu.yasuaki@...fujitsu.com>,
	Zhang Yanfei <zhangyanfei@...fujitsu.com>,
	Xishi Qiu <qiuxishi@...wei.com>,
	Vladimir Davydov <vdavydov@...allels.com>,
	Michal Nazarewicz <mina86@...a86.com>,
	Marek Szyprowski <m.szyprowski@...sung.com>
Subject: [PATCH] mm/page_alloc: Call kernel_map_pages in unset_migrateype_isolate

Commit 3c605096d315 ("mm/page_alloc: restrict max order of merging on isolated pageblock")
changed the logic of unset_migratetype_isolate to check the buddy allocator
and explicitly call __free_pages to merge. The page that is being freed in
this path never had prep_new_page called so set_page_refcounted is called
explicitly but there is no call to kernel_map_pages. With the default
kernel_map_pages this is mostly harmless but if kernel_map_pages does any
manipulation of the page tables (unmapping or setting pages to read only) this
may trigger a fault:

    alloc_contig_range test_pages_isolated(ceb00, ced00) failed
    Unable to handle kernel paging request at virtual address ffffffc0cec00000
    pgd = ffffffc045fc4000
    [ffffffc0cec00000] *pgd=0000000000000000
    Internal error: Oops: 9600004f [#1] PREEMPT SMP
    Modules linked in: exfatfs
    CPU: 1 PID: 23237 Comm: TimedEventQueue Not tainted 3.10.49-gc72ad36-dirty #1
    task: ffffffc03de52100 ti: ffffffc015388000 task.ti: ffffffc015388000
    PC is at memset+0xc8/0x1c0
    LR is at kernel_map_pages+0x1ec/0x244

Fix this by calling kernel_map_pages to ensure the page is set in the
page table properly

Fixes: 3c605096d315 ("mm/page_alloc: restrict max order of merging on isolated pageblock")
Cc: Naoya Horiguchi <n-horiguchi@...jp.nec.com>
Cc: Mel Gorman <mgorman@...e.de>
Cc: Rik van Riel <riel@...hat.com>
Cc: Yasuaki Ishimatsu <isimatu.yasuaki@...fujitsu.com>
Cc: Zhang Yanfei <zhangyanfei@...fujitsu.com>
Cc: Xishi Qiu <qiuxishi@...wei.com>
Cc: Vladimir Davydov <vdavydov@...allels.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@....com>
Cc: Gioh Kim <gioh.kim@....com>
Cc: Michal Nazarewicz <mina86@...a86.com>
Cc: Marek Szyprowski <m.szyprowski@...sung.com>
Cc: Vlastimil Babka <vbabka@...e.cz>
Signed-off-by: Laura Abbott <lauraa@...eaurora.org>
---
Note this was found on a backport to 3.10 and the code to make kernel_map_pages
change the page table state is currently out of tree. The original had stable,
so this may need to go into stable as well.
---
 mm/page_isolation.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/mm/page_isolation.c b/mm/page_isolation.c
index 72f5ac3..755a42c 100644
--- a/mm/page_isolation.c
+++ b/mm/page_isolation.c
@@ -103,6 +103,7 @@ void unset_migratetype_isolate(struct page *page, unsigned migratetype)
 
 			if (!is_migrate_isolate_page(buddy)) {
 				__isolate_free_page(page, order);
+				kernel_map_pages(page, (1 << order), 1);
 				set_page_refcounted(page);
 				isolated_page = page;
 			}
-- 
Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
This e-mail address will be inactive after March 20, 2015
Please contact privately for follow up after that date.

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