From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752678AbcBHKp3 (ORCPT ); Mon, 8 Feb 2016 05:45:29 -0500 Received: from r00tworld.com ([212.85.137.150]:47722 "EHLO r00tworld.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751976AbcBHKp1 (ORCPT ); Mon, 8 Feb 2016 05:45:27 -0500 X-Greylist: delayed 699 seconds by postgrey-1.27 at vger.kernel.org; Mon, 08 Feb 2016 05:45:26 EST From: "PaX Team" To: linux-tip-commits@vger.kernel.org, torvalds@linux-foundation.org, izumi.taku@jp.fujitsu.com, mingo@kernel.org, linux-kernel@vger.kernel.org, spender@grsecurity.net, y14sg1@comcast.net, akpm@linux-foundation.org, hpa@zytor.com, tglx@linutronix.de, laijs@cn.fujitsu.com, tangchen@cn.fujitsu.com, isimatu.yasuaki@jp.fujitsu.com, wency@cn.fujitsu.com, zhangyanfei@cn.fujitsu.com, imtangchen@gmail.com Date: Mon, 08 Feb 2016 11:33:06 +0100 MIME-Version: 1.0 Subject: Re: [tip:x86/mm] x86/mm/numa: Fix memory corruption on 32-bit NUMA kernels Reply-to: pageexec@freemail.hu CC: izumi.taku@jp.fujitsu.com, mingo@kernel.org, isimatu.yasuaki@jp.fujitsu.com, spender@grsecurity.net, wency@cn.fujitsu.com, tangchen@cn.fujitsu.com, laijs@cn.fujitsu.com, torvalds@linux-foundation.org, imtangchen@gmail.com, tglx@linutronix.de, hpa@zytor.com, y14sg1@comcast.net, akpm@linux-foundation.org, zhangyanfei@cn.fujitsu.com Message-ID: <56B86EE2.12451.11ACA8BE@pageexec.freemail.hu> In-reply-to: References: X-mailer: Pegasus Mail for Windows (4.70) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.12 (r00tworld.com [212.85.137.150]); Mon, 08 Feb 2016 11:33:04 +0100 (CET) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 8 Feb 2016 at 1:42, tip-bot for Ingo Molnar wrote: > y14sg1 reported that when running 32-bit NUMA kernels, > the grsecurity/PAX kernel patch flagged a size overflow in this function: > > PAX: size overflow detected in function x86_numa_init arch/x86/mm/numa.c:691 [...] > > ... the reason for the overflow is that memblock_set_node() takes physical > addresses as arguments, while the start/end variables used by > numa_clear_kernel_node_hotplug() are 'unsigned long', which is 32-bit on PAE > kernels, but which has 64-bit physical addresses. So we truncate a 64-bit > physical range to 32 bits and pass it to memblock_set_node(), which corrupts > memory on systems with physical addresses above 4GB. i think the truncated values go into memblock_clear_hotplug, not memblock_set_node. also the sideeffects are unclear to me, from a quick look these values seem to be used to look up some range in memblock, i don't know if that can lead to memory corruption per se or 'only' some logical bug later. > diff --git a/arch/x86/mm/numa.c b/arch/x86/mm/numa.c > index c3b3f65..d04f809 100644 > --- a/arch/x86/mm/numa.c > +++ b/arch/x86/mm/numa.c > @@ -469,7 +469,7 @@ static void __init numa_clear_kernel_node_hotplug(void) > { > int i, nid; > nodemask_t numa_kernel_nodes = NODE_MASK_NONE; > - unsigned long start, end; > + phys_addr_t start, end; > struct memblock_region *r; > > /* >