linux-kernel - Re: [tip:x86/mm] x86/mm/numa: Fix memory corruption on 32-bit NUMA kernels

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, 08 Feb 2016 11:33:06 +0100
From:	"PaX Team" <pageexec@...email.hu>
To:	linux-tip-commits@...r.kernel.org, torvalds@...ux-foundation.org,
	izumi.taku@...fujitsu.com, mingo@...nel.org,
	linux-kernel@...r.kernel.org, spender@...ecurity.net,
	y14sg1@...cast.net, akpm@...ux-foundation.org, hpa@...or.com,
	tglx@...utronix.de, laijs@...fujitsu.com, tangchen@...fujitsu.com,
	isimatu.yasuaki@...fujitsu.com, wency@...fujitsu.com,
	zhangyanfei@...fujitsu.com, imtangchen@...il.com
CC:	izumi.taku@...fujitsu.com, mingo@...nel.org,
	isimatu.yasuaki@...fujitsu.com, spender@...ecurity.net,
	wency@...fujitsu.com, tangchen@...fujitsu.com,
	laijs@...fujitsu.com, torvalds@...ux-foundation.org,
	imtangchen@...il.com, tglx@...utronix.de, hpa@...or.com,
	y14sg1@...cast.net, akpm@...ux-foundation.org,
	zhangyanfei@...fujitsu.com
Subject: Re: [tip:x86/mm] x86/mm/numa: Fix memory corruption on 32-bit NUMA kernels

On 8 Feb 2016 at 1:42, tip-bot for Ingo Molnar wrote:

> y14sg1 <y14sg1@...cast.net> 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;
> 
>   /*
>