linux-kernel - Re: v2.6.26-rc7: BUG: unable to handle kernel NULL pointer dereference

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

Date:	Tue, 24 Jun 2008 09:40:37 +0200
From:	"Vegard Nossum" <vegard.nossum@...il.com>
To:	"Rusty Russell" <rusty@...tcorp.com.au>,
	"Adrian Bunk" <bunk@...nel.org>, "Rafael J. Wysocki" <rjw@...k.pl>
Cc:	"Mike Travis" <travis@....com>,
	"Srivatsa Vaddagiri" <vatsa@...ibm.com>,
	linux-kernel@...r.kernel.org, "Gautham R Shenoy" <ego@...ibm.com>,
	"Zhang, Yanmin" <yanmin.zhang@...el.com>,
	"Heiko Carstens" <heiko.carstens@...ibm.com>
Subject: Re: v2.6.26-rc7: BUG: unable to handle kernel NULL pointer dereference

On Tue, Jun 24, 2008 at 3:36 AM, Rusty Russell <rusty@...tcorp.com.au> wrote:
> Vegard's analysis is flawed: just because cpu is offline, it still must be <
> nr_cpu_ids, which is based on possible cpus.  Unless something crazy is
> happening, but a quick grep doesn't reveal anyone manipulating nr_cpu_ids.

Hm, you are right and I was wrong. I'm sorry, it just seemed too
obvious to be any other way, and I made some assumptions about
nr_cpu_ids. (IIRC, nr_node_ids changes dynamically as nodes are
added/removed, so I assumed it was the same for CPUs.)

This doesn't change the fact that get_cpu_sysdev(cpu) returns NULL,
however. This variable, the per-cpu cpu_sys_device, is only ever
changed in two places, register_cpu() and unregister_cpu(); in
register_cpu(), it is set to

                per_cpu(cpu_sys_devices, num) = &cpu->sysdev;,

and in unregister_cpu(), it is set to

        per_cpu(cpu_sys_devices, logical_cpu) = NULL;.

So it seems *likely* that register_cpu() was never called (after the
previous unregister_cpu(), which we know happened successfully).

register_cpu() is called from arch_register_cpu(), which is called
from toplogy_init() and acpi_processor_hotadd_init(). Now, the
topology_init() call-chain is uninteresting, since it only happens at
boot. The question is whether acpi_processor_hotadd_init() will be
called if the arch-specific __cpu_up() fails...

But I am not able to follow that code.

Thanks for looking at this.

Vegard

PS: I'll withdraw the statement that this is probably a regression. It
seems more likely that nobody ever hit the "cpu failed to init" case
before.

-- 
"The animistic metaphor of the bug that maliciously sneaked in while
the programmer was not looking is intellectually dishonest as it
disguises that the error is the programmer's own creation."
	-- E. W. Dijkstra, EWD1036
--
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/