From: Ingo Molnar <mingo@kernel.org>
To: PaX Team <pageexec@freemail.hu>
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
Date: Mon, 8 Feb 2016 12:09:27 +0100 [thread overview]
Message-ID: <20160208110927.GA7270@gmail.com> (raw)
In-Reply-To: <56B86EE2.12451.11ACA8BE@pageexec.freemail.hu>
* 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>
prev parent reply other threads:[~2016-02-08 11:09 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <tip-2b54ab3c66d48a5887c9ba209a342d0b13cdefa8@git.kernel.org>
2016-02-08 10:33 ` [tip:x86/mm] x86/mm/numa: Fix memory corruption on 32-bit NUMA kernels PaX Team
2016-02-08 11:09 ` Ingo Molnar [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160208110927.GA7270@gmail.com \
--to=mingo@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=hpa@zytor.com \
--cc=imtangchen@gmail.com \
--cc=isimatu.yasuaki@jp.fujitsu.com \
--cc=izumi.taku@jp.fujitsu.com \
--cc=laijs@cn.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-tip-commits@vger.kernel.org \
--cc=pageexec@freemail.hu \
--cc=spender@grsecurity.net \
--cc=tangchen@cn.fujitsu.com \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=wency@cn.fujitsu.com \
--cc=y14sg1@comcast.net \
--cc=zhangyanfei@cn.fujitsu.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).