+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, [email protected] 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: 0000 [#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: ffff88002eb09700 ti: ffff88002eb88000 task.ti: ffff88002eb88000
> > RIP: 0010:[<ffffffff8143352d>] [<ffffffff8143352d>]
> > handle_irq_event_percpu+0xcd/0x6d0
> > RSP: 0018:ffff880053307e20 EFLAGS: 00010082
> > RAX: 0000000000000000 RBX: dffffc0000000000 RCX: 0000000000000001
> > RDX: 0000000000010000 RSI: ffff88002eb09f18 RDI: 0000000000000046
> > RBP: ffff880053307e70 R08: 0000000000000001 R09: 0000000000000001
> > R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000000
> > R13: ffff88002f1706b0 R14: ffffed0005e2e0de R15: ffff88002f1706b0
> > FS: 0000000000000000(0000) GS:ffff880053300000(0000)
> > knlGS:0000000000000000
> > CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> > CR2: 000000002000c000 CR3: 0000000000a82000 CR4: 00000000000006e0
> > Stack:
> > ffff88002f170680 000000002eb09700 1ffffffff0f464b2 fffffbfff0f464ba
> > 0000000400000000 ffff88002f170680 ffff88002f170720 ffff88002f1706b0
> > ffffed0005e2e0de ffff88002f1706b0 ffff880053307ea0 ffffffff81433bd7
> > Call Trace:
> > Call Trace:
> > <IRQ>
> > [<ffffffff81433bd7>] handle_irq_event+0xa7/0x140
> > kernel/irq/handle.c:193
> > [<ffffffff8143d7f1>] handle_edge_irq+0x1e1/0x8d0
> > kernel/irq/chip.c:623
> > [< inline >] generic_handle_irq_desc
> > kernel/include/linux/irqdesc.h:146
> > [<ffffffff811674e9>] 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
> > [<ffffffff81362e5f>] ? atomic_notifier_call_chain+0xbf/0x140
> > kernel/kernel/notifier.c:193
> > [<ffffffff81362da0>] ? __atomic_notifier_call_chain+0x150/0x150
> > kernel/include/linux/rcupdate.h:926
> > [<ffffffff811660bd>] do_IRQ+0x7d/0x1a0
> > kernel/arch/x86/kernel/irq.c:240
> > [<ffffffff85d889cc>] common_interrupt+0x8c/0x8c
> > kernel/arch/x86/entry/entry_64.S:520
> > [<ffffffff81222526>] ? 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
> > [<ffffffff811790a2>] default_idle+0x22/0x2a0
> > kernel/arch/x86/kernel/process.c:304
> > [<ffffffff8117a41a>] arch_cpu_idle+0xa/0x10
> > kernel/arch/x86/kernel/process.c:295
> > [<ffffffff813e50f8>] 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
> > [<ffffffff813e56bf>] cpu_startup_entry+0x4bf/0x610
> > kernel/kernel/sched/idle.c:300
> > [<ffffffff811fe6d8>] start_secondary+0x2a8/0x380
> > kernel/arch/x86/kernel/smpboot.c:251
> > [<ffffffff811fe430>] ? 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 [<ffffffff8143352d>] handle_irq_event_percpu+0xcd/0x6d0
> > kernel/kernel/irq/handle.c:144
> > RSP <ffff880053307e20>
> > ---[ 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 default:
> > 171 break;
> > 172 }
> > 173
> > 174 retval |= res;
> > 175 action = action->next;
> > 176 } while (action); //when action is null, it will
> > //cause a null pointer deref.
> >
> > The vulnerability was found in the latest Linux kernel version(4.4)
> > Could you allocate a CVE id for this? Thank you.
> >
> > ps:I have neither published it nor requested CVE from other CNA.
> >
> > Baozeng Ding
> >
> >
>
> Hello Baozeng,
>
> Thank you for reporting us this issue. We'll analyze it and respond to you
> soon. We'll assign CVE, once we confirm the vulnerability.
>
> Best Regards,
> --
> Adam Mariš / Red Hat Product Security
>
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