net/ipv6: null-ptr-deref in ip6_route_del/lock_acquire

Hi,

I've got the following error report while fuzzing the kernel with syzkaller.

On commit e5d56efc97f8240d0b5d66c03949382b6d7e5570 (Feb 26).

A reproducer and .config are attached.

kasan: CONFIG_KASAN_INLINE enabled
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault: 0000 [#1] SMP KASAN
Modules linked in:
CPU: 0 PID: 4045 Comm: a.out Not tainted 4.10.0+ #54
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
task: ffff88006b6bac00 task.stack: ffff88006a688000
RIP: 0010:__lock_acquire+0xac4/0x3270 kernel/locking/lockdep.c:3224
RSP: 0018:ffff88006a68f250 EFLAGS: 00010006
RAX: dffffc0000000000 RBX: dffffc0000000000 RCX: 0000000000000000
RDX: 0000000000000006 RSI: 0000000000000000 RDI: 1ffff1000d4d1ea4
RBP: ffff88006a68f788 R08: 0000000000000001 R09: 0000000000000000
R10: 0000000000000030 R11: 0000000000000000 R12: ffff88006b6bac00
R13: 0000000000000000 R14: ffffffff86e64ec0 R15: 0000000000000001
FS:  00007fda492ff700(0000) GS:ffff88006ca00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000208c4000 CR3: 000000006a7e9000 CR4: 00000000000006f0
Call Trace:
 lock_acquire+0x241/0x580 kernel/locking/lockdep.c:3753
 __raw_write_lock_bh ./include/linux/rwlock_api_smp.h:203
 _raw_write_lock_bh+0x3a/0x50 kernel/locking/spinlock.c:319
 __ip6_del_rt_siblings net/ipv6/route.c:2177
 ip6_route_del+0x4dd/0xa70 net/ipv6/route.c:2257
 ipv6_route_ioctl+0x62d/0x790 net/ipv6/route.c:2620
 inet6_ioctl+0xef/0x1e0 net/ipv6/af_inet6.c:520
 sock_do_ioctl+0x65/0xb0 net/socket.c:895
 sock_ioctl+0x28f/0x440 net/socket.c:993
 vfs_ioctl fs/ioctl.c:43
 do_vfs_ioctl+0x1bf/0x1780 fs/ioctl.c:683
 SYSC_ioctl fs/ioctl.c:698
 SyS_ioctl+0x8f/0xc0 fs/ioctl.c:689
 entry_SYSCALL_64_fastpath+0x1f/0xc2 arch/x86/entry/entry_64.S:204
RIP: 0033:0x7fda48a10b79
RSP: 002b:00007ffc4988a7b8 EFLAGS: 00000206 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 00007ffc4988a910 RCX: 00007fda48a10b79
RDX: 00000000208c4000 RSI: 000000000000890c RDI: 0000000000000003
RBP: 00000000004004a0 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000206 R12: 0000000000000000
R13: 00007ffc4988a910 R14: 0000000000000000 R15: 0000000000000000
Code: e9 03 f3 48 ab 48 81 c4 10 05 00 00 44 89 e8 5b 41 5c 41 5d 41
5e 41 5f 5d c3 4c 89 d2 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80>
3c 02 00 0f 85 07 26 00 00 49 81 3a c0 0a 1d 86 41 bf 00 00
RIP: __lock_acquire+0xac4/0x3270 RSP: ffff88006a68f250
---[ end trace f196d3fa9c5673b5 ]---
Kernel panic - not syncing: Fatal exception in interrupt
Kernel Offset: disabled
---[ end Kernel panic - not syncing: Fatal exception in interrupt

On Mon, Feb 27, 2017 at 7:28 AM, Andrey Konovalov [off-list ref] wrote:

Hi,

I've got the following error report while fuzzing the kernel with syzkaller.

On commit e5d56efc97f8240d0b5d66c03949382b6d7e5570 (Feb 26).

A reproducer and .config are attached.

kasan: CONFIG_KASAN_INLINE enabled
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault: 0000 [#1] SMP KASAN
Modules linked in:
CPU: 0 PID: 4045 Comm: a.out Not tainted 4.10.0+ #54
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
task: ffff88006b6bac00 task.stack: ffff88006a688000
RIP: 0010:__lock_acquire+0xac4/0x3270 kernel/locking/lockdep.c:3224
RSP: 0018:ffff88006a68f250 EFLAGS: 00010006
RAX: dffffc0000000000 RBX: dffffc0000000000 RCX: 0000000000000000
RDX: 0000000000000006 RSI: 0000000000000000 RDI: 1ffff1000d4d1ea4
RBP: ffff88006a68f788 R08: 0000000000000001 R09: 0000000000000000
R10: 0000000000000030 R11: 0000000000000000 R12: ffff88006b6bac00
R13: 0000000000000000 R14: ffffffff86e64ec0 R15: 0000000000000001
FS:  00007fda492ff700(0000) GS:ffff88006ca00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000208c4000 CR3: 000000006a7e9000 CR4: 00000000000006f0
Call Trace:
 lock_acquire+0x241/0x580 kernel/locking/lockdep.c:3753
 __raw_write_lock_bh ./include/linux/rwlock_api_smp.h:203
 _raw_write_lock_bh+0x3a/0x50 kernel/locking/spinlock.c:319
 __ip6_del_rt_siblings net/ipv6/route.c:2177
 ip6_route_del+0x4dd/0xa70 net/ipv6/route.c:2257
 ipv6_route_ioctl+0x62d/0x790 net/ipv6/route.c:2620
 inet6_ioctl+0xef/0x1e0 net/ipv6/af_inet6.c:520
 sock_do_ioctl+0x65/0xb0 net/socket.c:895
 sock_ioctl+0x28f/0x440 net/socket.c:993
 vfs_ioctl fs/ioctl.c:43
 do_vfs_ioctl+0x1bf/0x1780 fs/ioctl.c:683
 SYSC_ioctl fs/ioctl.c:698
 SyS_ioctl+0x8f/0xc0 fs/ioctl.c:689
 entry_SYSCALL_64_fastpath+0x1f/0xc2 arch/x86/entry/entry_64.S:204

The attached patch fixes this crash, but I am not sure if it is the
best way to fix this bug yet...

Thanks.

On Mon, Feb 27, 2017 at 8:59 PM, David Ahern [off-list ref] wrote:

On 2/27/17 10:11 AM, Cong Wang wrote:

quoted

The attached patch fixes this crash, but I am not sure if it is the
best way to fix this bug yet...

I'll take a look. I can not reproduce this using route or ip, so the
fuzzer is doing something interesting.

Hi David,

I've attached a simple reproducer to the report, it doesn't work for you?

Thanks!

On Mon, Feb 27, 2017 at 12:05 PM, Andrey Konovalov
[off-list ref] wrote:

On Mon, Feb 27, 2017 at 8:59 PM, David Ahern [off-list ref] wrote:

quoted

On 2/27/17 10:11 AM, Cong Wang wrote:

quoted

The attached patch fixes this crash, but I am not sure if it is the
best way to fix this bug yet...

I'll take a look. I can not reproduce this using route or ip, so the
fuzzer is doing something interesting.

Hi David,

I've attached a simple reproducer to the report, it doesn't work for you?

It works for me and I have verified the formal patch I sent.

On Mon, Feb 27, 2017 at 9:34 PM, Cong Wang [off-list ref] wrote:

On Mon, Feb 27, 2017 at 12:05 PM, Andrey Konovalov
[off-list ref] wrote:

quoted

On Mon, Feb 27, 2017 at 8:59 PM, David Ahern [off-list ref] wrote:

quoted

On 2/27/17 10:11 AM, Cong Wang wrote:

quoted

The attached patch fixes this crash, but I am not sure if it is the
best way to fix this bug yet...

I'll take a look. I can not reproduce this using route or ip, so the
fuzzer is doing something interesting.

Hi David,

I've attached a simple reproducer to the report, it doesn't work for you?

It works for me and I have verified the formal patch I sent.

Hi Cong,

That's what I thought when I read your message, thanks!

I was just confused by David saying that the fuzzer is doing something
interesting, when the reproducer is just an ioctl call on a socket.

--
You received this message because you are subscribed to the Google Groups "syzkaller" group.
To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

On 2/27/17 12:37 PM, Andrey Konovalov wrote:

That's what I thought when I read your message, thanks!

I was just confused by David saying that the fuzzer is doing something
interesting, when the reproducer is just an ioctl call on a socket.

It means I have a cold, recently off a plane and not processing what I
was reading.

The interesting part was intent to delete the null route, but then Cong
mentioned that in his commit message.

On 2/27/17 10:11 AM, Cong Wang wrote:

The attached patch fixes this crash, but I am not sure if it is the
best way to fix this bug yet...

I'll take a look. I can not reproduce this using route or ip, so the
fuzzer is doing something interesting.