On 8 Feb 2016 at 1:42, tip-bot for Ingo Molnar wrote:
> y14sg1 <y14sg1@xxxxxxxxxxx> 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;
>
> /*
>
--
To unsubscribe from this list: send the line "unsubscribe linux-tip-commits" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
|