On 02/26/2016, 10:23 AM, Jiri Slaby wrote:
> On 02/26/2016, 09:56 AM, Jiri Slaby wrote:
>>> I really don't see how it would happen here - that code doesn't look
>>> particularly odd.
>
> Funnily enough, this is what I got today, when booting 4.4.2 in qemu VM
> on my host.
>
> RIP crashing (ffffffff810f28d5) is action->dev_id dereference in
> handle_irq_event_percpu. Look:
> 0xffffffff810f28d5 <+101>: mov 0x8(%rbx),%rsi
> 0xffffffff810f28d9 <+105>: mov %r12d,%edi
> 0xffffffff810f28dc <+108>: callq *(%rbx)
> which is
> trace_irq_handler_entry(irq, action);
> res = action->handler(irq, action->dev_id);
> trace_irq_handler_exit(irq, action, res);
>
...
> So is this the same bug or not?
Seems not, actually. I think I need:
commit 570540d50710ed192e98e2f7f74578c9486b6b05
Author: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
Date: Wed Jan 13 14:07:25 2016 +0100
genirq: Validate action before dereferencing it in
handle_irq_event_percpu()
> [1] http://labs.suse.cz/jslaby/bug-968218/
>
> BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
> IP: [<ffffffff810f28d5>] handle_irq_event_percpu+0x65/0x340
> PGD 0
> Oops: 0000 [#1] PREEMPT SMP
> Modules linked in: ...
> CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.4.2-13.g19ca782-default #1
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS by
> qemu-project.org 04/01/2014
> task: ffffffff81e12540 ti: ffffffff81e00000 task.ti: ffffffff81e00000
> RIP: 0010:[<ffffffff810f28d5>] [<ffffffff810f28d5>]
> handle_irq_event_percpu+0x65/0x340
> RSP: 0018:ffff880093e03d88 EFLAGS: 00010002
> RAX: 0000000000000001 RBX: 0000000000000000 RCX: 000000000000000f
> RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000046
> RBP: ffff880093e03dc8 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000004
> R13: ffff880087c3b058 R14: 0000000000000000 R15: ffffffff81e03df8
> FS: 0000000000000000(0000) GS:ffff880093e00000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> CR2: 0000000000000008 CR3: 000000008a790000 CR4: 00000000000006f0
> Stack:
> ffff880087c3b000 0000000087c3b0d8 ffff880087c3b058 ffff880087c3b000
> ffff880087c3b0d8 ffff880087c3b058 0000000000000034 ffffffff81e03df8
> ffff880093e03df0 ffffffff810f2bec ffff880087c3b000 ffff880087c3b0d8
> Call Trace:
> [<ffffffff810f2bec>] handle_irq_event+0x3c/0x60
> [<ffffffff810f5f60>] handle_edge_irq+0x80/0x150
> [<ffffffff8101f49d>] handle_irq+0x1d/0x30
> [<ffffffff81751ac1>] do_IRQ+0x61/0x120
> [<ffffffff8174f80c>] common_interrupt+0x8c/0x8c
> Full inexact backtrace again:
>
> <IRQ>
> [<ffffffff810f2bec>] handle_irq_event+0x3c/0x60
> [<ffffffff810f5f60>] handle_edge_irq+0x80/0x150
> [<ffffffff8101f49d>] handle_irq+0x1d/0x30
> [<ffffffff81751ac1>] do_IRQ+0x61/0x120
> [<ffffffff8174f80c>] common_interrupt+0x8c/0x8c
> [<ffffffff8108bae7>] ? __do_softirq+0xa7/0x470
> [<ffffffff8108bae0>] ? __do_softirq+0xa0/0x470
> [<ffffffff8108c053>] irq_exit+0xb3/0xc0
> [<ffffffff81751bc2>] smp_apic_timer_interrupt+0x42/0x50
> [<ffffffff8174fb9c>] apic_timer_interrupt+0x8c/0xa0
> <EOI>
> [<ffffffff81067c96>] ? native_safe_halt+0x6/0x10
> [<ffffffff810dcaed>] ? trace_hardirqs_on+0xd/0x10
> [<ffffffff81027753>] default_idle+0x23/0x170
> [<ffffffff8102808f>] arch_cpu_idle+0xf/0x20
> [<ffffffff810d270a>] default_idle_call+0x2a/0x40
> [<ffffffff810d2b07>] cpu_startup_entry+0x387/0x400
> [<ffffffff8173fef6>] rest_init+0x136/0x140
> [<ffffffff81f59fe3>] start_kernel+0x499/0x4a6
> [<ffffffff81f59120>] ? early_idt_handler_array+0x120/0x120
> [<ffffffff81f59339>] x86_64_start_reservations+0x2a/0x2c
> [<ffffffff81f59476>] x86_64_start_kernel+0x13b/0x14a
> Code: 7e 48 8b 05 5e 58 e2 00 e8 79 8e 00 00 85 c0 74 0d 80 3d 54 3a e2
> 00 00 0f 84 db 01 00 00 65 ff 0d 01 96 f1 7e 0f 84 89 01 00 00 <48> 8b
> 73 08 44 89 e7 ff 13 41 89 c5 0f 1f 44 00 00 65 ff 05 e3
> RIP [<ffffffff810f28d5>] handle_irq_event_percpu+0x65/0x340
> RSP <ffff880093e03d88>
> CR2: 0000000000000008
>
> thanks,
>
--
js
suse labs
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html