| 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
| ||
|
Date: Thu, 01 Apr 2010 20:20:48 +0200
From: "Jan.Grossmann@...lnet.net" <Jan.Grossmann@...lnet.net>
To: "linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>
CC: Suresh Siddha <suresh.b.siddha@...el.com>,
"jbarnes@...tuousgeek.org" <jbarnes@...tuousgeek.org>,
"Woodhouse, David" <david.woodhouse@...el.com>,
"mingo@...e.hu" <mingo@...e.hu>,
"Han, Weidong" <weidong.han@...el.com>,
"Song, Youquan" <youquan.song@...el.com>,
LKML <linux-kernel@...r.kernel.org>,
"H. Peter Anvin" <hpa@...or.com>,
"x86@...nel.org" <x86@...nel.org>,
"stable@...nel.org" <stable@...nel.org>
Subject: Re: BUG: null pointer deref in dmar_ir_support
Suresh Siddha wrote:
> [Problem is in the x86 portion of the code, so copying x86 folks for
> their attention]
>
> On Wed, 2010-03-31 at 11:34 -0700, Jan.Grossmann@...lnet.net wrote:
>
>>>> [ 0.144012] BUG: unable to handle kernel NULL pointer dereference at
>>>> 0000000000000025
>>>> [ 0.148000] IP: [<ffffffff81199c96>] dmar_ir_support+0xb/0x14
>>>> [ 0.148000] PGD 0
>>>> [ 0.148000] Oops: 0000 [#1] SMP
>>>> [ 0.148000] last sysfs file:
>>>> [ 0.148000] CPU 0
>>>> [ 0.148000] Modules linked in:
>>>> [ 0.148000]
>>>> [ 0.148000] Pid: 1, comm: swapper Not tainted 2.6.34-rc2 #4 A8N-SLI
>>>> Premium/System Product Name
>>>> [ 0.148000] RIP: 0010:[<ffffffff81199c96>] [<ffffffff81199c96>]
>>>> dmar_ir_support+0xb/0x14
>>>> [ 0.148000] RSP: 0018:ffff88007fbe3e30 EFLAGS: 00010046
>>>> [ 0.148000] RAX: 0000000000000000 RBX: 0000000000000000 RCX:
>>>> 000000000000004c
>>>> [ 0.148000] RDX: ffffffff81762338 RSI: 0000000000000046 RDI:
>>>> 0000000000000010
>>>> [ 0.148000] RBP: ffff88007fbe3e30 R08: 0000000000000002 R09:
>>>> 000000000000000a
>>>> [ 0.148000] R10: 0000000000000005 R11: 0000000000000000 R12:
>>>> 0000000000000010
>>>> [ 0.148000] R13: 0000000000000246 R14: 0000000000000000 R15:
>>>> 000000000000e850
>>>> [ 0.148000] FS: 0000000000000000(0000) GS:ffff880001a00000(0000)
>>>> knlGS:0000000000000000
>>>> [ 0.148000] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
>>>> [ 0.148000] CR2: 0000000000000025 CR3: 0000000001625000 CR4:
>>>> 00000000000006f0
>>>> [ 0.148000] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
>>>> 0000000000000000
>>>> [ 0.148000] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7:
>>>> 0000000000000400
>>>> [ 0.148000] Process swapper (pid: 1, threadinfo ffff88007fbe2000,
>>>> task ffff88007fbde740)
>>>> [ 0.148000] Stack:
>>>> [ 0.148000] ffff88007fbe3e40 ffffffff816d1f01 ffff88007fbe3e50
>>>> ffffffff816b7fa6
>>>> [ 0.148000] <0> ffff88007fbe3ea0 ffffffff816b8095 ffff88007fbe3ec0
>>>> ffffffff8130122e
>>>> [ 0.148000] <0> ffff880000000008 ffff88007fbe3ed0 ffffffff8168ec20
>>>> 0000000000000200
>>>> [ 0.148000] Call Trace:
>>>> [ 0.148000] [<ffffffff816d1f01>] intr_remapping_supported+0x12/0x45
>>>> [ 0.148000] [<ffffffff816b7fa6>] enable_IR+0x9/0x5d
>>>> [ 0.148000] [<ffffffff816b8095>] enable_IR_x2apic+0x9b/0x1b6
>>>> [ 0.148000] [<ffffffff8130122e>] ? printk+0x3c/0x3e
>>>> [ 0.148000] [<ffffffff816b81f7>] APIC_init_uniprocessor+0x47/0x105
>>>> [ 0.148000] [<ffffffff816b62cf>] native_smp_prepare_cpus+0x190/0x365
>>>> [ 0.148000] [<ffffffff816ab5f5>] kernel_init+0x71/0x1f0
>>>> [ 0.148000] [<ffffffff810097e4>] kernel_thread_helper+0x4/0x10
>>>> [ 0.148000] [<ffffffff816ab584>] ? kernel_init+0x0/0x1f0
>>>> [ 0.148000] [<ffffffff810097e0>] ? kernel_thread_helper+0x0/0x10
>>>> [ 0.148000] Code: ff c7 06 00 00 00 00 48 8b 04 fd 80 ba 42 81 eb 0d
>>>> c7 06 02 00 00 00 48 c7 c0 e8 30 4a 81 c9 c3 48 8b 05 0e 4c 56 00 55 48
>>>> 89 e5 <0f> b6 40 25 c9 83 e0 01 c3 55 48 89 e5 e8 7c 8f 16 00 c9 c3 55
>>>> [ 0.148000] RIP [<ffffffff81199c96>] dmar_ir_support+0xb/0x14
>>>> [ 0.148000] RSP <ffff88007fbe3e30>
>>>> [ 0.148000] CR2: 0000000000000025
>>>>
>>>>
>
> Jan, Problem is that your system doesn't have proper SMP tables and we
> were doing enable_IR_x2apic() twice finally leading to this panic. Can
> you please check if the appended patch fixes your issue? Thanks.
> ---
>
> From: Suresh Siddha <suresh.b.siddha@...el.com>
> Subject: x86: fix calling enable_IR_x2apic() twice with SMP kernel on !SMP boards
>
> Jan Grossmann reported kernel boot panic while booting SMP kernel on his
> system with a single core cpu. SMP kernels call enable_IR_x2apic() from
> native_smp_prepare_cpus() and on platforms where the kernel doesn't
> find SMP configuration we ended up again calling enable_IR_x2apic() from the
> APIC_init_uniprocessor() call in the smp_sanity_check(). Thus leading to
> kernel panic.
>
> Don't call enable_IR_x2apic() and default_setup_apic_routing()
> from APIC_init_uniprocessor() in CONFIG_SMP case.
>
> Reported-by: Jan.Grossmann@...lnet.net
> Signed-off-by: Suresh Siddha <suresh.b.siddha@...el.com>
> Cc: stable@...nel.org [2.6.32, 2.6.33]
> ---
>
> diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
> index 00187f1..e5a4a1e 100644
> --- a/arch/x86/kernel/apic/apic.c
> +++ b/arch/x86/kernel/apic/apic.c
> @@ -1640,8 +1640,10 @@ int __init APIC_init_uniprocessor(void)
> }
> #endif
>
> +#ifndef CONFIG_SMP
> enable_IR_x2apic();
> default_setup_apic_routing();
> +#endif
>
> verify_local_APIC();
> connect_bsp_APIC();
>
>
>
>
The patch seems to work,
but now my kernel won't find any IDE, SATA or USB drives anymore and
then i end up with
Kernel panic - not syncing: VFS: Unable to mount root fs on
unknown-block(0,0)
of course.
the full boot log is attached.
thanks
Jan
View attachment "boot4.log" of type "text/x-log" (20511 bytes)
Powered by blists - more mailing lists