* net/ipv6: use-after-free in ip6_dst_ifdown
@ 2017-05-31 9:42 Andrey Konovalov
2017-05-31 16:45 ` Cong Wang
0 siblings, 1 reply; 6+ messages in thread
From: Andrey Konovalov @ 2017-05-31 9:42 UTC (permalink / raw)
To: David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, netdev, LKML, Eric Dumazet,
Cong Wang, David Ahern
Cc: Dmitry Vyukov, Kostya Serebryany, syzkaller
Hi,
I've got the following error report while fuzzing the kernel with syzkaller.
On commit 5ed02dbb497422bf225783f46e6eadd237d23d6b (4.12-rc3).
Unfortunately it's not reproducible.
==================================================================
BUG: KASAN: use-after-free in ip6_dst_ifdown+0x3cc/0x400 net/ipv6/route.c:422
Read of size 8 at addr ffff88006afa4ad8 by task syz-executor6/23554
CPU: 3 PID: 23554 Comm: syz-executor6 Not tainted 4.12.0-rc3+ #370
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:16 [inline]
dump_stack+0x292/0x395 lib/dump_stack.c:52
print_address_description+0x73/0x280 mm/kasan/report.c:252
kasan_report_error mm/kasan/report.c:351 [inline]
kasan_report+0x22b/0x340 mm/kasan/report.c:408
__asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:429
ip6_dst_ifdown+0x3cc/0x400 net/ipv6/route.c:422
dst_ifdown+0x75/0x230 net/core/dst.c:439
dst_dev_event+0xb1/0x230 net/core/dst.c:466
notifier_call_chain+0x145/0x2e0 kernel/notifier.c:93
__raw_notifier_call_chain kernel/notifier.c:394 [inline]
raw_notifier_call_chain+0x2d/0x40 kernel/notifier.c:401
call_netdevice_notifiers_info+0x51/0x90 net/core/dev.c:1649
call_netdevice_notifiers net/core/dev.c:1665 [inline]
__dev_notify_flags+0x1fd/0x320 net/core/dev.c:6640
dev_change_flags+0xf5/0x140 net/core/dev.c:6671
dev_ifsioc+0x62a/0x9f0 net/core/dev_ioctl.c:254
dev_ioctl+0x249/0x1160 net/core/dev_ioctl.c:532
sock_do_ioctl+0x94/0xb0 net/socket.c:913
sock_ioctl+0x28f/0x440 net/socket.c:1004
vfs_ioctl fs/ioctl.c:45 [inline]
do_vfs_ioctl+0x1bf/0x1660 fs/ioctl.c:685
SYSC_ioctl fs/ioctl.c:700 [inline]
SyS_ioctl+0x8f/0xc0 fs/ioctl.c:691
entry_SYSCALL_64_fastpath+0x1f/0xbe
RIP: 0033:0x446179
RSP: 002b:00007fd1da4bdc08 EFLAGS: 00000282 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 0000000000003220 RCX: 0000000000446179
RDX: 0000000020d34000 RSI: 0000000000008914 RDI: 0000000000000005
RBP: 00000000ffffffff R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000282 R12: 0000000000000005
R13: 0000000000000390 R14: 00000000006e1450 R15: 0000000000000000
Allocated by task 23235:
save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:59
save_stack+0x43/0xd0 mm/kasan/kasan.c:513
set_track mm/kasan/kasan.c:525 [inline]
kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:617
kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:555
slab_post_alloc_hook mm/slab.h:456 [inline]
slab_alloc_node mm/slub.c:2718 [inline]
__kmalloc_node_track_caller+0x20d/0x350 mm/slub.c:4303
__kmalloc_reserve.isra.32+0x41/0xd0 net/core/skbuff.c:138
__alloc_skb+0x157/0x770 net/core/skbuff.c:231
alloc_skb include/linux/skbuff.h:936 [inline]
alloc_skb_with_frags+0x12e/0x780 net/core/skbuff.c:4690
sock_alloc_send_pskb+0x804/0xa30 net/core/sock.c:2000
tun_alloc_skb drivers/net/tun.c:1144 [inline]
tun_get_user+0x91a/0x2e10 drivers/net/tun.c:1274
tun_chr_write_iter+0xd8/0x190 drivers/net/tun.c:1365
call_write_iter include/linux/fs.h:1734 [inline]
new_sync_write fs/read_write.c:497 [inline]
__vfs_write+0x483/0x760 fs/read_write.c:510
vfs_write+0x187/0x500 fs/read_write.c:558
SYSC_write fs/read_write.c:605 [inline]
SyS_write+0xfb/0x230 fs/read_write.c:597
entry_SYSCALL_64_fastpath+0x1f/0xbe
Freed by task 23235:
save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:59
save_stack+0x43/0xd0 mm/kasan/kasan.c:513
set_track mm/kasan/kasan.c:525 [inline]
kasan_slab_free+0x72/0xc0 mm/kasan/kasan.c:590
slab_free_hook mm/slub.c:1357 [inline]
slab_free_freelist_hook mm/slub.c:1379 [inline]
slab_free mm/slub.c:2961 [inline]
kfree+0xe8/0x2b0 mm/slub.c:3882
skb_free_head+0x74/0xb0 net/core/skbuff.c:579
skb_release_data+0x3ce/0x4a0 net/core/skbuff.c:610
skb_release_all+0x4a/0x60 net/core/skbuff.c:669
__kfree_skb+0x15/0x20 net/core/skbuff.c:683
kfree_skb+0x16e/0x4e0 net/core/skbuff.c:704
llc_rcv+0x5c7/0xed0 net/llc/llc_input.c:214
__netif_receive_skb_core+0x1ad1/0x3400 net/core/dev.c:4216
__netif_receive_skb+0x2c/0x1b0 net/core/dev.c:4254
netif_receive_skb_internal+0x240/0x1b20 net/core/dev.c:4416
netif_receive_skb+0xae/0x3b0 net/core/dev.c:4440
tun_rx_batched.isra.40+0x5e5/0x8c0 drivers/net/tun.c:1167
tun_get_user+0x100d/0x2e10 drivers/net/tun.c:1339
tun_chr_write_iter+0xd8/0x190 drivers/net/tun.c:1365
call_write_iter include/linux/fs.h:1734 [inline]
new_sync_write fs/read_write.c:497 [inline]
__vfs_write+0x483/0x760 fs/read_write.c:510
vfs_write+0x187/0x500 fs/read_write.c:558
SYSC_write fs/read_write.c:605 [inline]
SyS_write+0xfb/0x230 fs/read_write.c:597
entry_SYSCALL_64_fastpath+0x1f/0xbe
The buggy address belongs to the object at ffff88006afa4ad8
which belongs to the cache kmalloc-1024 of size 1024
The buggy address is located 0 bytes inside of
1024-byte region [ffff88006afa4ad8, ffff88006afa4ed8)
The buggy address belongs to the page:
page:ffffea0001abe800 count:1 mapcount:0 mapping: (null)
index:0x0 compound_mapcount: 0
flags: 0x500000000008100(slab|head)
raw: 0500000000008100 0000000000000000 0000000000000000 0000000100170017
raw: ffffea00017ef420 ffffea0001aaa420 ffff88003e80efc0 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff88006afa4980: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff88006afa4a00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>ffff88006afa4a80: fc fc fc fc fc fc fc fc fc fc fc fb fb fb fb fb
^
ffff88006afa4b00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff88006afa4b80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==================================================================
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: net/ipv6: use-after-free in ip6_dst_ifdown 2017-05-31 9:42 net/ipv6: use-after-free in ip6_dst_ifdown Andrey Konovalov @ 2017-05-31 16:45 ` Cong Wang 2017-05-31 16:55 ` Eric Dumazet 0 siblings, 1 reply; 6+ messages in thread From: Cong Wang @ 2017-05-31 16:45 UTC (permalink / raw) To: Andrey Konovalov Cc: David S. Miller, Alexey Kuznetsov, James Morris, Hideaki YOSHIFUJI, Patrick McHardy, netdev, LKML, Eric Dumazet, David Ahern, Dmitry Vyukov, Kostya Serebryany, syzkaller On Wed, May 31, 2017 at 2:42 AM, Andrey Konovalov <andreyknvl@google.com> wrote: > Hi, > > I've got the following error report while fuzzing the kernel with syzkaller. > > On commit 5ed02dbb497422bf225783f46e6eadd237d23d6b (4.12-rc3). > > Unfortunately it's not reproducible. > > ================================================================== > BUG: KASAN: use-after-free in ip6_dst_ifdown+0x3cc/0x400 net/ipv6/route.c:422 > Read of size 8 at addr ffff88006afa4ad8 by task syz-executor6/23554 This one is very interesting. Here we are at: if (dev != loopback_dev) { if (idev && idev->dev == dev) { struct inet6_dev *loopback_idev = in6_dev_get(loopback_dev); if (loopback_idev) { rt->rt6i_idev = loopback_idev; in6_dev_put(idev); } } } clearly no skb involved, it looks like idev is the one used-after-free. But below it is actually skb which is allocated and freed... > > CPU: 3 PID: 23554 Comm: syz-executor6 Not tainted 4.12.0-rc3+ #370 > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 > Call Trace: > __dump_stack lib/dump_stack.c:16 [inline] > dump_stack+0x292/0x395 lib/dump_stack.c:52 > print_address_description+0x73/0x280 mm/kasan/report.c:252 > kasan_report_error mm/kasan/report.c:351 [inline] > kasan_report+0x22b/0x340 mm/kasan/report.c:408 > __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:429 > ip6_dst_ifdown+0x3cc/0x400 net/ipv6/route.c:422 > dst_ifdown+0x75/0x230 net/core/dst.c:439 > dst_dev_event+0xb1/0x230 net/core/dst.c:466 > notifier_call_chain+0x145/0x2e0 kernel/notifier.c:93 > __raw_notifier_call_chain kernel/notifier.c:394 [inline] > raw_notifier_call_chain+0x2d/0x40 kernel/notifier.c:401 > call_netdevice_notifiers_info+0x51/0x90 net/core/dev.c:1649 > call_netdevice_notifiers net/core/dev.c:1665 [inline] > __dev_notify_flags+0x1fd/0x320 net/core/dev.c:6640 > dev_change_flags+0xf5/0x140 net/core/dev.c:6671 > dev_ifsioc+0x62a/0x9f0 net/core/dev_ioctl.c:254 > dev_ioctl+0x249/0x1160 net/core/dev_ioctl.c:532 > sock_do_ioctl+0x94/0xb0 net/socket.c:913 > sock_ioctl+0x28f/0x440 net/socket.c:1004 > vfs_ioctl fs/ioctl.c:45 [inline] > do_vfs_ioctl+0x1bf/0x1660 fs/ioctl.c:685 > SYSC_ioctl fs/ioctl.c:700 [inline] > SyS_ioctl+0x8f/0xc0 fs/ioctl.c:691 > entry_SYSCALL_64_fastpath+0x1f/0xbe > RIP: 0033:0x446179 > RSP: 002b:00007fd1da4bdc08 EFLAGS: 00000282 ORIG_RAX: 0000000000000010 > RAX: ffffffffffffffda RBX: 0000000000003220 RCX: 0000000000446179 > RDX: 0000000020d34000 RSI: 0000000000008914 RDI: 0000000000000005 > RBP: 00000000ffffffff R08: 0000000000000000 R09: 0000000000000000 > R10: 0000000000000000 R11: 0000000000000282 R12: 0000000000000005 > R13: 0000000000000390 R14: 00000000006e1450 R15: 0000000000000000 > > Allocated by task 23235: > save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:59 > save_stack+0x43/0xd0 mm/kasan/kasan.c:513 > set_track mm/kasan/kasan.c:525 [inline] > kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:617 > kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:555 > slab_post_alloc_hook mm/slab.h:456 [inline] > slab_alloc_node mm/slub.c:2718 [inline] > __kmalloc_node_track_caller+0x20d/0x350 mm/slub.c:4303 > __kmalloc_reserve.isra.32+0x41/0xd0 net/core/skbuff.c:138 > __alloc_skb+0x157/0x770 net/core/skbuff.c:231 > alloc_skb include/linux/skbuff.h:936 [inline] > alloc_skb_with_frags+0x12e/0x780 net/core/skbuff.c:4690 > sock_alloc_send_pskb+0x804/0xa30 net/core/sock.c:2000 > tun_alloc_skb drivers/net/tun.c:1144 [inline] > tun_get_user+0x91a/0x2e10 drivers/net/tun.c:1274 > tun_chr_write_iter+0xd8/0x190 drivers/net/tun.c:1365 > call_write_iter include/linux/fs.h:1734 [inline] > new_sync_write fs/read_write.c:497 [inline] > __vfs_write+0x483/0x760 fs/read_write.c:510 > vfs_write+0x187/0x500 fs/read_write.c:558 > SYSC_write fs/read_write.c:605 [inline] > SyS_write+0xfb/0x230 fs/read_write.c:597 > entry_SYSCALL_64_fastpath+0x1f/0xbe > > Freed by task 23235: > save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:59 > save_stack+0x43/0xd0 mm/kasan/kasan.c:513 > set_track mm/kasan/kasan.c:525 [inline] > kasan_slab_free+0x72/0xc0 mm/kasan/kasan.c:590 > slab_free_hook mm/slub.c:1357 [inline] > slab_free_freelist_hook mm/slub.c:1379 [inline] > slab_free mm/slub.c:2961 [inline] > kfree+0xe8/0x2b0 mm/slub.c:3882 > skb_free_head+0x74/0xb0 net/core/skbuff.c:579 > skb_release_data+0x3ce/0x4a0 net/core/skbuff.c:610 > skb_release_all+0x4a/0x60 net/core/skbuff.c:669 > __kfree_skb+0x15/0x20 net/core/skbuff.c:683 > kfree_skb+0x16e/0x4e0 net/core/skbuff.c:704 > llc_rcv+0x5c7/0xed0 net/llc/llc_input.c:214 > __netif_receive_skb_core+0x1ad1/0x3400 net/core/dev.c:4216 > __netif_receive_skb+0x2c/0x1b0 net/core/dev.c:4254 > netif_receive_skb_internal+0x240/0x1b20 net/core/dev.c:4416 > netif_receive_skb+0xae/0x3b0 net/core/dev.c:4440 > tun_rx_batched.isra.40+0x5e5/0x8c0 drivers/net/tun.c:1167 > tun_get_user+0x100d/0x2e10 drivers/net/tun.c:1339 > tun_chr_write_iter+0xd8/0x190 drivers/net/tun.c:1365 > call_write_iter include/linux/fs.h:1734 [inline] > new_sync_write fs/read_write.c:497 [inline] > __vfs_write+0x483/0x760 fs/read_write.c:510 > vfs_write+0x187/0x500 fs/read_write.c:558 > SYSC_write fs/read_write.c:605 [inline] > SyS_write+0xfb/0x230 fs/read_write.c:597 > entry_SYSCALL_64_fastpath+0x1f/0xbe > > The buggy address belongs to the object at ffff88006afa4ad8 > which belongs to the cache kmalloc-1024 of size 1024 > The buggy address is located 0 bytes inside of > 1024-byte region [ffff88006afa4ad8, ffff88006afa4ed8) > The buggy address belongs to the page: > page:ffffea0001abe800 count:1 mapcount:0 mapping: (null) > index:0x0 compound_mapcount: 0 > flags: 0x500000000008100(slab|head) > raw: 0500000000008100 0000000000000000 0000000000000000 0000000100170017 > raw: ffffea00017ef420 ffffea0001aaa420 ffff88003e80efc0 0000000000000000 > page dumped because: kasan: bad access detected > > Memory state around the buggy address: > ffff88006afa4980: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc > ffff88006afa4a00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc >>ffff88006afa4a80: fc fc fc fc fc fc fc fc fc fc fc fb fb fb fb fb > ^ > ffff88006afa4b00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb > ffff88006afa4b80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb > ================================================================== ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: net/ipv6: use-after-free in ip6_dst_ifdown 2017-05-31 16:45 ` Cong Wang @ 2017-05-31 16:55 ` Eric Dumazet 2017-05-31 22:49 ` Cong Wang 0 siblings, 1 reply; 6+ messages in thread From: Eric Dumazet @ 2017-05-31 16:55 UTC (permalink / raw) To: Cong Wang Cc: Andrey Konovalov, David S. Miller, Alexey Kuznetsov, James Morris, Hideaki YOSHIFUJI, Patrick McHardy, netdev, LKML, David Ahern, Dmitry Vyukov, Kostya Serebryany, syzkaller On Wed, May 31, 2017 at 9:45 AM, Cong Wang <xiyou.wangcong@gmail.com> wrote: > On Wed, May 31, 2017 at 2:42 AM, Andrey Konovalov <andreyknvl@google.com> wrote: >> Hi, >> >> I've got the following error report while fuzzing the kernel with syzkaller. >> >> On commit 5ed02dbb497422bf225783f46e6eadd237d23d6b (4.12-rc3). >> >> Unfortunately it's not reproducible. >> >> ================================================================== >> BUG: KASAN: use-after-free in ip6_dst_ifdown+0x3cc/0x400 net/ipv6/route.c:422 >> Read of size 8 at addr ffff88006afa4ad8 by task syz-executor6/23554 > > > This one is very interesting. > > Here we are at: > > if (dev != loopback_dev) { > if (idev && idev->dev == dev) { > struct inet6_dev *loopback_idev = > in6_dev_get(loopback_dev); > if (loopback_idev) { > rt->rt6i_idev = loopback_idev; > in6_dev_put(idev); > } > } > } > > clearly no skb involved, it looks like idev is the one used-after-free. > > But below it is actually skb which is allocated and freed... > skb->head was a kmalloc(X) with X = 1024 in this case. So it is very possible the two different objects (skb->head and idev ) were accidentally using the same slab (1024 bytes). KASAN only remember the last pair of alloc/free for a particular memory zone. > >> >> CPU: 3 PID: 23554 Comm: syz-executor6 Not tainted 4.12.0-rc3+ #370 >> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 >> Call Trace: >> __dump_stack lib/dump_stack.c:16 [inline] >> dump_stack+0x292/0x395 lib/dump_stack.c:52 >> print_address_description+0x73/0x280 mm/kasan/report.c:252 >> kasan_report_error mm/kasan/report.c:351 [inline] >> kasan_report+0x22b/0x340 mm/kasan/report.c:408 >> __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:429 >> ip6_dst_ifdown+0x3cc/0x400 net/ipv6/route.c:422 >> dst_ifdown+0x75/0x230 net/core/dst.c:439 >> dst_dev_event+0xb1/0x230 net/core/dst.c:466 >> notifier_call_chain+0x145/0x2e0 kernel/notifier.c:93 >> __raw_notifier_call_chain kernel/notifier.c:394 [inline] >> raw_notifier_call_chain+0x2d/0x40 kernel/notifier.c:401 >> call_netdevice_notifiers_info+0x51/0x90 net/core/dev.c:1649 >> call_netdevice_notifiers net/core/dev.c:1665 [inline] >> __dev_notify_flags+0x1fd/0x320 net/core/dev.c:6640 >> dev_change_flags+0xf5/0x140 net/core/dev.c:6671 >> dev_ifsioc+0x62a/0x9f0 net/core/dev_ioctl.c:254 >> dev_ioctl+0x249/0x1160 net/core/dev_ioctl.c:532 >> sock_do_ioctl+0x94/0xb0 net/socket.c:913 >> sock_ioctl+0x28f/0x440 net/socket.c:1004 >> vfs_ioctl fs/ioctl.c:45 [inline] >> do_vfs_ioctl+0x1bf/0x1660 fs/ioctl.c:685 >> SYSC_ioctl fs/ioctl.c:700 [inline] >> SyS_ioctl+0x8f/0xc0 fs/ioctl.c:691 >> entry_SYSCALL_64_fastpath+0x1f/0xbe >> RIP: 0033:0x446179 >> RSP: 002b:00007fd1da4bdc08 EFLAGS: 00000282 ORIG_RAX: 0000000000000010 >> RAX: ffffffffffffffda RBX: 0000000000003220 RCX: 0000000000446179 >> RDX: 0000000020d34000 RSI: 0000000000008914 RDI: 0000000000000005 >> RBP: 00000000ffffffff R08: 0000000000000000 R09: 0000000000000000 >> R10: 0000000000000000 R11: 0000000000000282 R12: 0000000000000005 >> R13: 0000000000000390 R14: 00000000006e1450 R15: 0000000000000000 >> >> Allocated by task 23235: >> save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:59 >> save_stack+0x43/0xd0 mm/kasan/kasan.c:513 >> set_track mm/kasan/kasan.c:525 [inline] >> kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:617 >> kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:555 >> slab_post_alloc_hook mm/slab.h:456 [inline] >> slab_alloc_node mm/slub.c:2718 [inline] >> __kmalloc_node_track_caller+0x20d/0x350 mm/slub.c:4303 >> __kmalloc_reserve.isra.32+0x41/0xd0 net/core/skbuff.c:138 >> __alloc_skb+0x157/0x770 net/core/skbuff.c:231 >> alloc_skb include/linux/skbuff.h:936 [inline] >> alloc_skb_with_frags+0x12e/0x780 net/core/skbuff.c:4690 >> sock_alloc_send_pskb+0x804/0xa30 net/core/sock.c:2000 >> tun_alloc_skb drivers/net/tun.c:1144 [inline] >> tun_get_user+0x91a/0x2e10 drivers/net/tun.c:1274 >> tun_chr_write_iter+0xd8/0x190 drivers/net/tun.c:1365 >> call_write_iter include/linux/fs.h:1734 [inline] >> new_sync_write fs/read_write.c:497 [inline] >> __vfs_write+0x483/0x760 fs/read_write.c:510 >> vfs_write+0x187/0x500 fs/read_write.c:558 >> SYSC_write fs/read_write.c:605 [inline] >> SyS_write+0xfb/0x230 fs/read_write.c:597 >> entry_SYSCALL_64_fastpath+0x1f/0xbe >> >> Freed by task 23235: >> save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:59 >> save_stack+0x43/0xd0 mm/kasan/kasan.c:513 >> set_track mm/kasan/kasan.c:525 [inline] >> kasan_slab_free+0x72/0xc0 mm/kasan/kasan.c:590 >> slab_free_hook mm/slub.c:1357 [inline] >> slab_free_freelist_hook mm/slub.c:1379 [inline] >> slab_free mm/slub.c:2961 [inline] >> kfree+0xe8/0x2b0 mm/slub.c:3882 >> skb_free_head+0x74/0xb0 net/core/skbuff.c:579 >> skb_release_data+0x3ce/0x4a0 net/core/skbuff.c:610 >> skb_release_all+0x4a/0x60 net/core/skbuff.c:669 >> __kfree_skb+0x15/0x20 net/core/skbuff.c:683 >> kfree_skb+0x16e/0x4e0 net/core/skbuff.c:704 >> llc_rcv+0x5c7/0xed0 net/llc/llc_input.c:214 >> __netif_receive_skb_core+0x1ad1/0x3400 net/core/dev.c:4216 >> __netif_receive_skb+0x2c/0x1b0 net/core/dev.c:4254 >> netif_receive_skb_internal+0x240/0x1b20 net/core/dev.c:4416 >> netif_receive_skb+0xae/0x3b0 net/core/dev.c:4440 >> tun_rx_batched.isra.40+0x5e5/0x8c0 drivers/net/tun.c:1167 >> tun_get_user+0x100d/0x2e10 drivers/net/tun.c:1339 >> tun_chr_write_iter+0xd8/0x190 drivers/net/tun.c:1365 >> call_write_iter include/linux/fs.h:1734 [inline] >> new_sync_write fs/read_write.c:497 [inline] >> __vfs_write+0x483/0x760 fs/read_write.c:510 >> vfs_write+0x187/0x500 fs/read_write.c:558 >> SYSC_write fs/read_write.c:605 [inline] >> SyS_write+0xfb/0x230 fs/read_write.c:597 >> entry_SYSCALL_64_fastpath+0x1f/0xbe >> >> The buggy address belongs to the object at ffff88006afa4ad8 >> which belongs to the cache kmalloc-1024 of size 1024 >> The buggy address is located 0 bytes inside of >> 1024-byte region [ffff88006afa4ad8, ffff88006afa4ed8) >> The buggy address belongs to the page: >> page:ffffea0001abe800 count:1 mapcount:0 mapping: (null) >> index:0x0 compound_mapcount: 0 >> flags: 0x500000000008100(slab|head) >> raw: 0500000000008100 0000000000000000 0000000000000000 0000000100170017 >> raw: ffffea00017ef420 ffffea0001aaa420 ffff88003e80efc0 0000000000000000 >> page dumped because: kasan: bad access detected >> >> Memory state around the buggy address: >> ffff88006afa4980: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc >> ffff88006afa4a00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc >>>ffff88006afa4a80: fc fc fc fc fc fc fc fc fc fc fc fb fb fb fb fb >> ^ >> ffff88006afa4b00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >> ffff88006afa4b80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >> ================================================================== ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: net/ipv6: use-after-free in ip6_dst_ifdown 2017-05-31 16:55 ` Eric Dumazet @ 2017-05-31 22:49 ` Cong Wang 2017-06-01 1:17 ` David Ahern 0 siblings, 1 reply; 6+ messages in thread From: Cong Wang @ 2017-05-31 22:49 UTC (permalink / raw) To: Eric Dumazet Cc: Andrey Konovalov, David S. Miller, Alexey Kuznetsov, James Morris, Hideaki YOSHIFUJI, Patrick McHardy, netdev, LKML, David Ahern, Dmitry Vyukov, Kostya Serebryany, syzkaller On Wed, May 31, 2017 at 9:55 AM, Eric Dumazet <edumazet@google.com> wrote: > On Wed, May 31, 2017 at 9:45 AM, Cong Wang <xiyou.wangcong@gmail.com> wrote: >> On Wed, May 31, 2017 at 2:42 AM, Andrey Konovalov <andreyknvl@google.com> wrote: >>> Hi, >>> >>> I've got the following error report while fuzzing the kernel with syzkaller. >>> >>> On commit 5ed02dbb497422bf225783f46e6eadd237d23d6b (4.12-rc3). >>> >>> Unfortunately it's not reproducible. >>> >>> ================================================================== >>> BUG: KASAN: use-after-free in ip6_dst_ifdown+0x3cc/0x400 net/ipv6/route.c:422 >>> Read of size 8 at addr ffff88006afa4ad8 by task syz-executor6/23554 >> >> >> This one is very interesting. >> >> Here we are at: >> >> if (dev != loopback_dev) { >> if (idev && idev->dev == dev) { >> struct inet6_dev *loopback_idev = >> in6_dev_get(loopback_dev); >> if (loopback_idev) { >> rt->rt6i_idev = loopback_idev; >> in6_dev_put(idev); >> } >> } >> } >> >> clearly no skb involved, it looks like idev is the one used-after-free. >> >> But below it is actually skb which is allocated and freed... >> > > skb->head was a kmalloc(X) with X = 1024 in this case. > > So it is very possible the two different objects (skb->head and idev ) > were accidentally using the same slab (1024 bytes). > > KASAN only remember the last pair of alloc/free for a particular memory zone. I see. So that memory area was freed for idev and then allocated and freed again for skb->head, this happened so quick that the use-after-free happened after it... Therefore we lost the track on where we free the idev. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: net/ipv6: use-after-free in ip6_dst_ifdown 2017-05-31 22:49 ` Cong Wang @ 2017-06-01 1:17 ` David Ahern 2017-06-01 12:00 ` Andrey Konovalov 0 siblings, 1 reply; 6+ messages in thread From: David Ahern @ 2017-06-01 1:17 UTC (permalink / raw) To: Cong Wang, Eric Dumazet Cc: Andrey Konovalov, David S. Miller, Alexey Kuznetsov, James Morris, Hideaki YOSHIFUJI, Patrick McHardy, netdev, LKML, David Ahern, Dmitry Vyukov, Kostya Serebryany, syzkaller On 5/31/17 4:49 PM, Cong Wang wrote: >>>> ================================================================== >>>> BUG: KASAN: use-after-free in ip6_dst_ifdown+0x3cc/0x400 net/ipv6/route.c:422 >>>> Read of size 8 at addr ffff88006afa4ad8 by task syz-executor6/23554 >>> >>> >>> This one is very interesting. >>> >>> Here we are at: >>> >>> if (dev != loopback_dev) { >>> if (idev && idev->dev == dev) { >>> struct inet6_dev *loopback_idev = >>> in6_dev_get(loopback_dev); >>> if (loopback_idev) { >>> rt->rt6i_idev = loopback_idev; >>> in6_dev_put(idev); >>> } >>> } >>> } >>> >>> clearly no skb involved, it looks like idev is the one used-after-free. >>> >>> But below it is actually skb which is allocated and freed... >>> >> >> skb->head was a kmalloc(X) with X = 1024 in this case. >> >> So it is very possible the two different objects (skb->head and idev ) >> were accidentally using the same slab (1024 bytes). >> >> KASAN only remember the last pair of alloc/free for a particular memory zone. > > I see. So that memory area was freed for idev and then allocated > and freed again for skb->head, this happened so quick that the > use-after-free happened after it... Therefore we lost the track on where > we free the idev. > Andrey: can you add this to your runs? If it triggers again, we can see if this use-after-free is another problem where the dst hit the gc list and came back into the IPv6 FIB. The location of the idev entry in rt6_info is after the size of rtable so if this is an IPv4 dst on the IPv6 list it could trigger that warning. diff --git a/net/ipv6/route.c b/net/ipv6/route.c index 9d9b5bbea153..237f42144b3e 100644 --- a/net/ipv6/route.c +++ b/net/ipv6/route.c @@ -418,6 +418,7 @@ static void ip6_dst_ifdown(struct dst_entry *dst, struct net_device *dev, struct net_device *loopback_dev = dev_net(dev)->loopback_dev; +WARN_ON(dst->ops->family != AF_INET6); if (dev != loopback_dev) { if (idev && idev->dev == dev) { struct inet6_dev *loopback_idev = ^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: net/ipv6: use-after-free in ip6_dst_ifdown 2017-06-01 1:17 ` David Ahern @ 2017-06-01 12:00 ` Andrey Konovalov 0 siblings, 0 replies; 6+ messages in thread From: Andrey Konovalov @ 2017-06-01 12:00 UTC (permalink / raw) To: David Ahern Cc: Cong Wang, Eric Dumazet, David S. Miller, Alexey Kuznetsov, James Morris, Hideaki YOSHIFUJI, Patrick McHardy, netdev, LKML, David Ahern, Dmitry Vyukov, Kostya Serebryany, syzkaller On Thu, Jun 1, 2017 at 3:17 AM, David Ahern <dsahern@gmail.com> wrote: > On 5/31/17 4:49 PM, Cong Wang wrote: >>>>> ================================================================== >>>>> BUG: KASAN: use-after-free in ip6_dst_ifdown+0x3cc/0x400 net/ipv6/route.c:422 >>>>> Read of size 8 at addr ffff88006afa4ad8 by task syz-executor6/23554 >>>> >>>> >>>> This one is very interesting. >>>> >>>> Here we are at: >>>> >>>> if (dev != loopback_dev) { >>>> if (idev && idev->dev == dev) { >>>> struct inet6_dev *loopback_idev = >>>> in6_dev_get(loopback_dev); >>>> if (loopback_idev) { >>>> rt->rt6i_idev = loopback_idev; >>>> in6_dev_put(idev); >>>> } >>>> } >>>> } >>>> >>>> clearly no skb involved, it looks like idev is the one used-after-free. >>>> >>>> But below it is actually skb which is allocated and freed... >>>> >>> >>> skb->head was a kmalloc(X) with X = 1024 in this case. >>> >>> So it is very possible the two different objects (skb->head and idev ) >>> were accidentally using the same slab (1024 bytes). >>> >>> KASAN only remember the last pair of alloc/free for a particular memory zone. >> >> I see. So that memory area was freed for idev and then allocated >> and freed again for skb->head, this happened so quick that the >> use-after-free happened after it... Therefore we lost the track on where >> we free the idev. >> > > Andrey: can you add this to your runs? If it triggers again, we can see > if this use-after-free is another problem where the dst hit the gc list > and came back into the IPv6 FIB. The location of the idev entry in > rt6_info is after the size of rtable so if this is an IPv4 dst on the > IPv6 list it could trigger that warning. Done, now testing with your patch. BTW, I've also been getting the report below, which looks related. However it's a null-ptr-deref, so much less useful info is present. This one is being triggered much more often, I'll see if I'm able to extract a reproducer. 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 Dumping ftrace buffer: (ftrace buffer empty) Modules linked in: CPU: 0 PID: 26651 Comm: syz-executor1 Not tainted 4.12.0-rc3+ #373 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 task: ffff88003bcdc480 task.stack: ffff880028ff0000 RIP: 0010:rt6_uncached_list_flush_dev net/ipv6/route.c:167 [inline] RIP: 0010:rt6_ifdown+0x3cf/0x910 net/ipv6/route.c:2824 RSP: 0018:ffff880028ff6e38 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffc900033c6000 RDX: 0000000000010000 RSI: ffffffff83e4d153 RDI: ffff88003ec25444 RBP: ffff880028ff6f98 R08: 0000000000000001 R09: 43743c8b00000000 R10: ffff88003bcdcc90 R11: dffffc0000000000 R12: ffff88003dc1aa98 R13: ffff88003dc1aa80 R14: ffff88003a7d0000 R15: dffffc0000000000 FS: 00007fb818f8a700(0000) GS:ffff88003ec00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000705dcc CR3: 0000000068757000 CR4: 00000000000006f0 Call Trace: addrconf_ifdown+0x1a3/0x1a30 net/ipv6/addrconf.c:3588 addrconf_notify+0x1ca/0x2630 net/ipv6/addrconf.c:3512 notifier_call_chain+0x145/0x2e0 kernel/notifier.c:93 __raw_notifier_call_chain kernel/notifier.c:394 [inline] raw_notifier_call_chain+0x2d/0x40 kernel/notifier.c:401 call_netdevice_notifiers_info+0x51/0x90 net/core/dev.c:1649 call_netdevice_notifiers net/core/dev.c:1665 [inline] __dev_notify_flags+0x1fd/0x320 net/core/dev.c:6640 dev_change_flags+0xf5/0x140 net/core/dev.c:6671 dev_ifsioc+0x62a/0x9f0 net/core/dev_ioctl.c:254 dev_ioctl+0x249/0x1160 net/core/dev_ioctl.c:532 sock_do_ioctl+0x94/0xb0 net/socket.c:913 sock_ioctl+0x28f/0x440 net/socket.c:1004 vfs_ioctl fs/ioctl.c:45 [inline] do_vfs_ioctl+0x1bf/0x1660 fs/ioctl.c:685 SYSC_ioctl fs/ioctl.c:700 [inline] SyS_ioctl+0x8f/0xc0 fs/ioctl.c:691 entry_SYSCALL_64_fastpath+0x1f/0xbe RIP: 0033:0x446179 RSP: 002b:00007fb818f89c08 EFLAGS: 00000282 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000000000003220 RCX: 0000000000446179 RDX: 00000000206fe000 RSI: 0000000000008914 RDI: 0000000000000005 RBP: 00000000ffffffff R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000282 R12: 0000000000000005 R13: 0000000000000000 R14: 00007fb818f8a9c0 R15: 00007fb818f8a700 Code: 49 8b 9d 58 01 00 00 4c 89 e0 48 c1 e8 03 42 80 3c 38 00 0f 85 6d 04 00 00 49 8b 45 18 48 89 85 f0 fe ff ff 48 89 d8 48 c1 e8 03 <42> 80 3c 38 00 0f 85 5d 04 00 00 4c 3b 33 0f 84 d7 01 00 00 e8 RIP: rt6_uncached_list_flush_dev net/ipv6/route.c:167 [inline] RSP: ffff880028ff6e38 RIP: rt6_ifdown+0x3cf/0x910 net/ipv6/route.c:2824 RSP: ffff880028ff6e38 ---[ end trace 9e62f05a0ea34b53 ]--- > > diff --git a/net/ipv6/route.c b/net/ipv6/route.c > index 9d9b5bbea153..237f42144b3e 100644 > --- a/net/ipv6/route.c > +++ b/net/ipv6/route.c > @@ -418,6 +418,7 @@ static void ip6_dst_ifdown(struct dst_entry *dst, > struct net_device *dev, > struct net_device *loopback_dev = > dev_net(dev)->loopback_dev; > > +WARN_ON(dst->ops->family != AF_INET6); > if (dev != loopback_dev) { > if (idev && idev->dev == dev) { > struct inet6_dev *loopback_idev = ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2017-06-01 12:00 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2017-05-31 9:42 net/ipv6: use-after-free in ip6_dst_ifdown Andrey Konovalov 2017-05-31 16:45 ` Cong Wang 2017-05-31 16:55 ` Eric Dumazet 2017-05-31 22:49 ` Cong Wang 2017-06-01 1:17 ` David Ahern 2017-06-01 12:00 ` Andrey Konovalov
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).