Re: kernel/irq: Null-ptr deref on handle_irq_event_percpu function
On Wed, 16 Mar 2016, Baozeng Ding wrote: > +linux-kernel and irq maitainer. > > On Thu, Feb 25, 2016 at 04:16:10AM -0500, Red Hat Product Security wrote: > > > > > > I cannot produce the bug, but by taking a look at the > > > code(irq/handle.c line176), it may > > > casue a null pointer deref: > > > > > > http://lxr.free-electrons.com/source/kernel/irq/handle.c#L176 That's the upstream code which is different from what you are pasting. > > > 174 retval |= res; > > > 175 action = action->next; > > > 176 } while (action); //when action is null, it will > > > //cause a null pointer deref. That lacks upstream commit 570540d507 or stable 4.4.y commit 827685a637 Thanks, tglx
Re: kernel/irq: Null-ptr deref on handle_irq_event_percpu function
On Wed, 16 Mar 2016, Baozeng Ding wrote: > +linux-kernel and irq maitainer. > > On Thu, Feb 25, 2016 at 04:16:10AM -0500, Red Hat Product Security wrote: > > > > > > I cannot produce the bug, but by taking a look at the > > > code(irq/handle.c line176), it may > > > casue a null pointer deref: > > > > > > http://lxr.free-electrons.com/source/kernel/irq/handle.c#L176 That's the upstream code which is different from what you are pasting. > > > 174 retval |= res; > > > 175 action = action->next; > > > 176 } while (action); //when action is null, it will > > > //cause a null pointer deref. That lacks upstream commit 570540d507 or stable 4.4.y commit 827685a637 Thanks, tglx
kernel/irq: Null-ptr deref on handle_irq_event_percpu function
+linux-kernel and irq maitainer.
Best Regards,
Baozeng Ding
On Thu, Feb 25, 2016 at 04:16:10AM -0500, Red Hat Product Security wrote:
> On Wed Feb 24 08:44:30 2016, splovi...@gmail.com wrote:
> > Dear all,
> >
> > I hit the following bug when fuzzing kernel using
> > syzkaller:
> >
> > kasan: CONFIG_KASAN_INLINE enabled
> > kasan: GPF could be caused by NULL-ptr deref or user memory
> > accessgeneral protection fault: [#1] SMP KASAN
> > Modules linked in:
> > CPU: 3 PID: 0 Comm: swapper/3 Not tainted 4.4.0+ #5
> > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
> > rel-1.8.2-0-g33fbe13 by qemu-project.org 04/01/2014
> > task: 88002eb09700 ti: 88002eb88000 task.ti: 88002eb88000
> > RIP: 0010:[] []
> > handle_irq_event_percpu+0xcd/0x6d0
> > RSP: 0018:880053307e20 EFLAGS: 00010082
> > RAX: RBX: dc00 RCX: 0001
> > RDX: 0001 RSI: 88002eb09f18 RDI: 0046
> > RBP: 880053307e70 R08: 0001 R09: 0001
> > R10: R11: 0001 R12:
> > R13: 88002f1706b0 R14: ed0005e2e0de R15: 88002f1706b0
> > FS: () GS:88005330()
> > knlGS:
> > CS: 0010 DS: ES: CR0: 8005003b
> > CR2: 2000c000 CR3: 00a82000 CR4: 06e0
> > Stack:
> > 88002f170680 2eb09700 10f464b2 fbfff0f464ba
> > 0004 88002f170680 88002f170720 88002f1706b0
> > ed0005e2e0de 88002f1706b0 880053307ea0 81433bd7
> > Call Trace:
> > Call Trace:
> >
> > [] handle_irq_event+0xa7/0x140
> > kernel/irq/handle.c:193
> > [] handle_edge_irq+0x1e1/0x8d0
> > kernel/irq/chip.c:623
> > [< inline >] generic_handle_irq_desc
> > kernel/include/linux/irqdesc.h:146
> > [] handle_irq+0x109/0x2a0
> > kernel/arch/x86/kernel/irq_64.c:78
> > [< inline >] ? rcu_lock_release
> > kernel/include/linux/rcupdate.h:495
> > [< inline >] ? rcu_read_unlock
> > kernel/include/linux/rcupdate.h:930
> > [< inline >] ? __atomic_notifier_call_chain
> > kernel/kernel/notifier.c:184
> > [] ? atomic_notifier_call_chain+0xbf/0x140
> > kernel/kernel/notifier.c:193
> > [] ? __atomic_notifier_call_chain+0x150/0x150
> > kernel/include/linux/rcupdate.h:926
> > [] do_IRQ+0x7d/0x1a0
> > kernel/arch/x86/kernel/irq.c:240
> > [] common_interrupt+0x8c/0x8c
> > kernel/arch/x86/entry/entry_64.S:520
> > [] ? native_safe_halt+0x6/0x10
> > kernel/arch/x86/include/asm/irqflags.h:49
> > [< inline >] arch_safe_halt
> > kernel/arch/x86/include/asm/paravirt.h:117
> > [] default_idle+0x22/0x2a0
> > kernel/arch/x86/kernel/process.c:304
> > [] arch_cpu_idle+0xa/0x10
> > kernel/arch/x86/kernel/process.c:295
> > [] default_idle_call+0x48/0x70
> > kernel/kernel/sched/idle.c:92
> > [< inline >] cpuidle_idle_call
> > kernel/kernel/sched/idle.c:156
> > [< inline >] cpu_idle_loop kernel/kernel/sched/idle.c:252
> > [] cpu_startup_entry+0x4bf/0x610
> > kernel/kernel/sched/idle.c:300
> > [] start_secondary+0x2a8/0x380
> > kernel/arch/x86/kernel/smpboot.c:251
> > [] ? set_cpu_sibling_map+0x1890/0x1890
> > kernel/include/linux/topology.h:80
> > Code: 48 89 45 c8 48 c7 c0 90 25 a3 87 48 c1 e8 03 48 89 45 c0 e9 4f
> > 01 00 00 e8 31 8e 0e 00 4c 89 e0 48 c1 e8 03 65 ff 0d 23 0a be 7e <80>
> > 3c 18 00 0f 85 8c 05 00 00 49 8d 7c 24 08 4d 8b 34 24 48 89
> > RIP [< inline >] __preempt_count_sub
> > kernel/arch/x86/include/asm/preempt.h:74
> > RIP [< inline >] rcu_read_unlock_sched_notrace
> > kernel/include/linux/rcupdate.h:1020
> > RIP [< inline >] trace_irq_handler_entry
> > kernel/include/trace/events/irq.h:52
> > RIP [] handle_irq_event_percpu+0xcd/0x6d0
> > kernel/kernel/irq/handle.c:144
> > RSP
> > ---[ end trace 0984a7cc502bc978 ]---
> > Kernel panic - not syncing: Fatal exception in interrupt
> > Kernel Offset: disabled
> > ---[ end Kernel panic - not syncing: Fatal exception in interrupt
> >
> >
> > I cannot produce the bug, but by taking a look at the
> > code(irq/handle.c line176), it may
> > casue a null pointer deref:
> >
> > http://lxr.free-electrons.com/source/kernel/irq/handle.c#L176
> >
> > 141 do {
> > 142 irqreturn_t res;
> > 143
> > 144 trace_irq_handler_entry(irq, action);
> > 145 res = action->handler(irq, action->dev_id);
> > 146 trace_irq_handler_exit(irq, action, res);
> > 147
> > 148 if (WARN_ONCE(!irqs_disabled(),"irq %u handler %pF
> > enabled interrupts\n",
> > 149 irq, action->handler))
> > 150 local_irq_disable();
> > 151
> > 152 switch (res) {
> > 153 case IRQ_WAKE_THREAD:
> > 154 /*
> > 155 * Catch drivers which return WAKE_THREAD
> > but
> > 156 * did not set up a thread function
> > 157 */
> > 158 if (unlikely(!action->thread_fn)) {
> > 159 warn_no_thread(irq, action);
> > 160 break;
> > 161 }
> > 162
> > 163 __irq_wake_thread(desc, action);
> > 164
> > 165 /* Fall through to add to randomness */
> > 166 case IRQ_HANDLED:
> > 167 flags |= action->flags;
> > 168 break;
> > 169
> > 170
kernel/irq: Null-ptr deref on handle_irq_event_percpu function
+linux-kernel and irq maitainer.
Best Regards,
Baozeng Ding
On Thu, Feb 25, 2016 at 04:16:10AM -0500, Red Hat Product Security wrote:
> On Wed Feb 24 08:44:30 2016, splovi...@gmail.com wrote:
> > Dear all,
> >
> > I hit the following bug when fuzzing kernel using
> > syzkaller:
> >
> > kasan: CONFIG_KASAN_INLINE enabled
> > kasan: GPF could be caused by NULL-ptr deref or user memory
> > accessgeneral protection fault: [#1] SMP KASAN
> > Modules linked in:
> > CPU: 3 PID: 0 Comm: swapper/3 Not tainted 4.4.0+ #5
> > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
> > rel-1.8.2-0-g33fbe13 by qemu-project.org 04/01/2014
> > task: 88002eb09700 ti: 88002eb88000 task.ti: 88002eb88000
> > RIP: 0010:[] []
> > handle_irq_event_percpu+0xcd/0x6d0
> > RSP: 0018:880053307e20 EFLAGS: 00010082
> > RAX: RBX: dc00 RCX: 0001
> > RDX: 0001 RSI: 88002eb09f18 RDI: 0046
> > RBP: 880053307e70 R08: 0001 R09: 0001
> > R10: R11: 0001 R12:
> > R13: 88002f1706b0 R14: ed0005e2e0de R15: 88002f1706b0
> > FS: () GS:88005330()
> > knlGS:
> > CS: 0010 DS: ES: CR0: 8005003b
> > CR2: 2000c000 CR3: 00a82000 CR4: 06e0
> > Stack:
> > 88002f170680 2eb09700 10f464b2 fbfff0f464ba
> > 0004 88002f170680 88002f170720 88002f1706b0
> > ed0005e2e0de 88002f1706b0 880053307ea0 81433bd7
> > Call Trace:
> > Call Trace:
> >
> > [] handle_irq_event+0xa7/0x140
> > kernel/irq/handle.c:193
> > [] handle_edge_irq+0x1e1/0x8d0
> > kernel/irq/chip.c:623
> > [< inline >] generic_handle_irq_desc
> > kernel/include/linux/irqdesc.h:146
> > [] handle_irq+0x109/0x2a0
> > kernel/arch/x86/kernel/irq_64.c:78
> > [< inline >] ? rcu_lock_release
> > kernel/include/linux/rcupdate.h:495
> > [< inline >] ? rcu_read_unlock
> > kernel/include/linux/rcupdate.h:930
> > [< inline >] ? __atomic_notifier_call_chain
> > kernel/kernel/notifier.c:184
> > [] ? atomic_notifier_call_chain+0xbf/0x140
> > kernel/kernel/notifier.c:193
> > [] ? __atomic_notifier_call_chain+0x150/0x150
> > kernel/include/linux/rcupdate.h:926
> > [] do_IRQ+0x7d/0x1a0
> > kernel/arch/x86/kernel/irq.c:240
> > [] common_interrupt+0x8c/0x8c
> > kernel/arch/x86/entry/entry_64.S:520
> > [] ? native_safe_halt+0x6/0x10
> > kernel/arch/x86/include/asm/irqflags.h:49
> > [< inline >] arch_safe_halt
> > kernel/arch/x86/include/asm/paravirt.h:117
> > [] default_idle+0x22/0x2a0
> > kernel/arch/x86/kernel/process.c:304
> > [] arch_cpu_idle+0xa/0x10
> > kernel/arch/x86/kernel/process.c:295
> > [] default_idle_call+0x48/0x70
> > kernel/kernel/sched/idle.c:92
> > [< inline >] cpuidle_idle_call
> > kernel/kernel/sched/idle.c:156
> > [< inline >] cpu_idle_loop kernel/kernel/sched/idle.c:252
> > [] cpu_startup_entry+0x4bf/0x610
> > kernel/kernel/sched/idle.c:300
> > [] start_secondary+0x2a8/0x380
> > kernel/arch/x86/kernel/smpboot.c:251
> > [] ? set_cpu_sibling_map+0x1890/0x1890
> > kernel/include/linux/topology.h:80
> > Code: 48 89 45 c8 48 c7 c0 90 25 a3 87 48 c1 e8 03 48 89 45 c0 e9 4f
> > 01 00 00 e8 31 8e 0e 00 4c 89 e0 48 c1 e8 03 65 ff 0d 23 0a be 7e <80>
> > 3c 18 00 0f 85 8c 05 00 00 49 8d 7c 24 08 4d 8b 34 24 48 89
> > RIP [< inline >] __preempt_count_sub
> > kernel/arch/x86/include/asm/preempt.h:74
> > RIP [< inline >] rcu_read_unlock_sched_notrace
> > kernel/include/linux/rcupdate.h:1020
> > RIP [< inline >] trace_irq_handler_entry
> > kernel/include/trace/events/irq.h:52
> > RIP [] handle_irq_event_percpu+0xcd/0x6d0
> > kernel/kernel/irq/handle.c:144
> > RSP
> > ---[ end trace 0984a7cc502bc978 ]---
> > Kernel panic - not syncing: Fatal exception in interrupt
> > Kernel Offset: disabled
> > ---[ end Kernel panic - not syncing: Fatal exception in interrupt
> >
> >
> > I cannot produce the bug, but by taking a look at the
> > code(irq/handle.c line176), it may
> > casue a null pointer deref:
> >
> > http://lxr.free-electrons.com/source/kernel/irq/handle.c#L176
> >
> > 141 do {
> > 142 irqreturn_t res;
> > 143
> > 144 trace_irq_handler_entry(irq, action);
> > 145 res = action->handler(irq, action->dev_id);
> > 146 trace_irq_handler_exit(irq, action, res);
> > 147
> > 148 if (WARN_ONCE(!irqs_disabled(),"irq %u handler %pF
> > enabled interrupts\n",
> > 149 irq, action->handler))
> > 150 local_irq_disable();
> > 151
> > 152 switch (res) {
> > 153 case IRQ_WAKE_THREAD:
> > 154 /*
> > 155 * Catch drivers which return WAKE_THREAD
> > but
> > 156 * did not set up a thread function
> > 157 */
> > 158 if (unlikely(!action->thread_fn)) {
> > 159 warn_no_thread(irq, action);
> > 160 break;
> > 161 }
> > 162
> > 163 __irq_wake_thread(desc, action);
> > 164
> > 165 /* Fall through to add to randomness */
> > 166 case IRQ_HANDLED:
> > 167 flags |= action->flags;
> > 168 break;
> > 169
> > 170
