Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1328929

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

Show all headers | View raw

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

Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread

Thread

Re: [tip:x86/mm] x86/mm/numa: Fix memory corruption on 32-bit NUMA kernels "PaX Team" <pageexec@freemail.hu> - 2016-02-08 11:50 +0100
  Re: [tip:x86/mm] x86/mm/numa: Fix memory corruption on 32-bit NUMA  kernels Ingo Molnar <mingo@kernel.org> - 2016-02-08 12:10 +0100

csiph-web