linux-kernel - [patch] x86, numa: Add error handling for bad cpu-to-node mappings

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-prev] [day] [month] [year] [list]

Date:	Thu, 13 Jan 2011 15:05:40 -0800 (PST)
From:	David Rientjes <rientjes@...gle.com>
To:	Jesper Juhl <jj@...osbits.net>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>
cc:	linux-kernel@...r.kernel.org, x86@...nel.org,
	Yinghai Lu <yinghai@...nel.org>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: [patch] x86, numa: Add error handling for bad cpu-to-node mappings

On Thu, 13 Jan 2011, Jesper Juhl wrote:

> In arch/x86/mm/numa_64.c::debug_cpumask_set_cpu() we call 
> early_cpu_to_node() which may return NUMA_NO_NODE (which has the value 
> -1). This value is subsequently used as an index into 
> the 'node_to_cpumask_map' array and '-1' is not going to fly too wel as an 
> array index here.
> 
> This code comes from commit d906f0eb2f0e6d1a24c479f69a9c39e7e45c5ae8
> "x86, numa: Fix CONFIG_DEBUG_PER_CPU_MAPS without NUMA emulation".
> 
> I must admit I have no idea what the best way to deal with this is, so 
> I'll just report it.
> 

Thanks for the report.

If generic code were actually passing cpu's to numa_add_cpu() under the 
defconfig that did not have valid early_cpu_to_node() mappings, then we'd 
see the problem already since we use early_cpu_to_node() as an index into 
an array with no error checking.

These mappings are all initialized to NUMA_NO_NODE before any mapping is 
initialized, so there's nothing new in the CONFIG_DEBUG_PER_CPU_MAPS 
variant of early_cpu_to_node() returning NUMA_NO_NODE when the cpu is not 
possible (generic code doesn't call numa_add_cpu() for non-possible cpus).

If you have a crash report for a CONFIG_DEBUG_PER_CPU_MAPS kernel, though, 
we can find why early_cpu_to_node() isn't being properly initialized prior 
to numa_add_cpu().

I agree that we should have some basic error handling in the debug case to 
check for this, though.  Please take a look at the following.

x86, numa: Add error handling for bad cpu-to-node mappings

CONFIG_DEBUG_PER_CPU_MAPS may return NUMA_NO_NODE when an
early_cpu_to_node() mapping hasn't been initialized.  In such a case, it
emits a warning and continues without an issue but callers may try to use
the return value to index into an array.

We can catch those errors and fail silently since a warning has already
been emitted.  No current user of numa_add_cpu() requires this error
checking to avoid a crash, but it's better to be proactive in case a
future user happens to have a bug and a user tries to diagnose it with 
CONFIG_DEBUG_PER_CPU_MAPS.

Reported-by: Jesper Juhl <jj@...osbits.net>
Signed-off-by: David Rientjes <rientjes@...gle.com>
---
 arch/x86/mm/numa_64.c |    8 ++++++++
 1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/arch/x86/mm/numa_64.c b/arch/x86/mm/numa_64.c
--- a/arch/x86/mm/numa_64.c
+++ b/arch/x86/mm/numa_64.c
@@ -839,6 +839,10 @@ static struct cpumask __cpuinit *debug_cpumask_set_cpu(int cpu, int enable)
 	struct cpumask *mask;
 	char buf[64];

+	if (node == NUMA_NO_NODE) {
+		/* early_cpu_to_node() already emits a warning and trace */
+		return NULL;
+	}
 	mask = node_to_cpumask_map[node];
 	if (!mask) {
 		pr_err("node_to_cpumask_map[%i] NULL\n", node);
@@ -877,6 +881,10 @@ static void __cpuinit numa_set_cpumask(int cpu, int enable)
 	struct cpumask *mask;
 	int i;

+	if (node == NUMA_NO_NODE) {
+		/* early_cpu_to_node() already emits a warning and trace */
+		return;
+	}
 	for_each_online_node(i) {
 		unsigned long addr;

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/