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

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

[PaX Team]

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

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

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

[Ingo Molnar]

* PaX Team <pageexec@freemail.hu> wrote:

> On 8 Feb 2016 at 1:42, tip-bot for Ingo Molnar wrote:
> 
> > y14sg1 <y14sg1@comcast.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.

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>