From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751183AbcBHLJe (ORCPT ); Mon, 8 Feb 2016 06:09:34 -0500 Received: from mail-wm0-f68.google.com ([74.125.82.68]:36185 "EHLO mail-wm0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750781AbcBHLJc (ORCPT ); Mon, 8 Feb 2016 06:09:32 -0500 Date: Mon, 8 Feb 2016 12:09:27 +0100 From: Ingo Molnar To: PaX Team Cc: linux-tip-commits@vger.kernel.org, torvalds@linux-foundation.org, izumi.taku@jp.fujitsu.com, 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 Subject: Re: [tip:x86/mm] x86/mm/numa: Fix memory corruption on 32-bit NUMA kernels Message-ID: <20160208110927.GA7270@gmail.com> References: <56B86EE2.12451.11ACA8BE@pageexec.freemail.hu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56B86EE2.12451.11ACA8BE@pageexec.freemail.hu> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * PaX Team wrote: > 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. Indeed. > 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. The truncated/bogus range is also used to (potentially) split up and extend the memblock array, so in theory it could cause other side effects as well. But you are right that it's not memory corruption per se, it 'only' feeds semi-random data to a historically fragile memory setup facility. I'll fix the changelog. Thanks, Ingo>