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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Thu, 10 Jul 2008 21:10:41 +0200
From:	"Vegard Nossum" <vegard.nossum@...il.com>
To:	"Zhang, Yanmin" <yanmin_zhang@...ux.intel.com>
Cc:	"Rusty Russell" <rusty@...tcorp.com.au>,
	"Mike Travis" <travis@....com>, "Adrian Bunk" <bunk@...nel.org>,
	"Srivatsa Vaddagiri" <vatsa@...ibm.com>,
	linux-kernel@...r.kernel.org, "Gautham R Shenoy" <ego@...ibm.com>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	"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 10:06 AM, Zhang, Yanmin
<yanmin_zhang@...ux.intel.com> wrote:
> In function _cpu_up, the panic happens when calling __raw_notifier_call_chain
> at the second time. Kernel doesn't panic when calling it at the first time. If
> just say because of nr_cpu_ids, that's not right.
>
> By checking source codes, I find function do_boot_cpu is the culprit.
> Consider below call chain:
>  _cpu_up=>__cpu_up=>smp_ops.cpu_up=>native_cpu_up=>do_boot_cpu.
>
> So do_boot_cpu is called in the end. In do_boot_cpu, if boot_error==true,
> cpu_clear(cpu, cpu_possible_map) is executed. So later on, when _cpu_up
> calls __raw_notifier_call_chain at the second time to report CPU_UP_CANCELED,
> because this cpu is already cleared from cpu_possible_map, get_cpu_sysdev returns
> NULL.
>
> Many resources are related to cpu_possible_map, so it's better not to change it.
>
> Below patch against 2.6.26-rc7 fixes it by removing the bit clearing in cpu_possible_map.
>
> Vegard, would you like to help test it?

Yay! I just hit this again with your patch applied

Inquiring remote APIC #1...
... APIC #1 ID: failed
... APIC #1 VERSION: failed
... APIC #1 SPIV: failed

and it works correctly, no NULL pointer error this time :-)

I know it's applied to mainline already, actually with this tag too,
even though I wasn't able to confirm it before:

    Tested-by: Vegard Nossum <vegard.nossum@...il.com>

Thanks :-)


Vegard

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