Re: KASAN: use-after-free Read in __dev_queue_xmit

[Eric Dumazet]

On Wed, Jan 3, 2018 at 8:58 PM, syzbot
<syzbot+71d74a5406d02057d559@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
> Hello,
>
> syzkaller hit the following crash on
> 37759fa6d0fa9e4d6036d19ac12f555bfc0aeafd
> git://git.cmpxchg.org/linux-mmots.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is attached.
> C reproducer is attached
> syzkaller reproducer is attached. See https://goo.gl/kgGztJ
> for information about syzkaller reproducers
>
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+71d74a5406d02057d559@xxxxxxxxxxxxxxxxxxxxxxxxx
> It will help syzbot understand when the bug is fixed. See footer for
> details.
> If you forward the report, please keep this part and the footer.
>
> ==================================================================
> BUG: KASAN: use-after-free in __tcp_hdrlen include/linux/tcp.h:35 [inline]
> BUG: KASAN: use-after-free in tcp_hdrlen include/linux/tcp.h:40 [inline]
> BUG: KASAN: use-after-free in qdisc_pkt_len_init net/core/dev.c:3160
> [inline]
> BUG: KASAN: use-after-free in __dev_queue_xmit+0x20d3/0x2200
> net/core/dev.c:3465
> Read of size 2 at addr ffff8801cb360d38 by task syzkaller769484/3147
>
> CPU: 0 PID: 3147 Comm: syzkaller769484 Not tainted 4.15.0-rc4-mm1+ #49
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
>  __dump_stack lib/dump_stack.c:17 [inline]
>  dump_stack+0x194/0x257 lib/dump_stack.c:53
>  print_address_description+0x73/0x250 mm/kasan/report.c:256
>  kasan_report_error mm/kasan/report.c:355 [inline]
>  kasan_report+0x23b/0x360 mm/kasan/report.c:413
>  __asan_report_load2_noabort+0x14/0x20 mm/kasan/report.c:432
>  __tcp_hdrlen include/linux/tcp.h:35 [inline]
>  tcp_hdrlen include/linux/tcp.h:40 [inline]
>  qdisc_pkt_len_init net/core/dev.c:3160 [inline]
>  __dev_queue_xmit+0x20d3/0x2200 net/core/dev.c:3465
>  dev_queue_xmit+0x17/0x20 net/core/dev.c:3554
>  packet_snd net/packet/af_packet.c:2943 [inline]
>  packet_sendmsg+0x3ad5/0x60a0 net/packet/af_packet.c:2968
>  sock_sendmsg_nosec net/socket.c:628 [inline]
>  sock_sendmsg+0xca/0x110 net/socket.c:638
>  sock_write_iter+0x31a/0x5d0 net/socket.c:907
>  call_write_iter include/linux/fs.h:1776 [inline]
>  new_sync_write fs/read_write.c:469 [inline]
>  __vfs_write+0x684/0x970 fs/read_write.c:482
>  vfs_write+0x189/0x510 fs/read_write.c:544
>  SYSC_write fs/read_write.c:589 [inline]
>  SyS_write+0xef/0x220 fs/read_write.c:581
>  entry_SYSCALL_64_fastpath+0x1f/0x96
> RIP: 0033:0x444b89
> RSP: 002b:00000000007eff78 EFLAGS: 00000293 ORIG_RAX: 0000000000000001
> RAX: ffffffffffffffda RBX: 00007fff91d02bb0 RCX: 0000000000444b89
> RDX: 000000000000005d RSI: 0000000020384000 RDI: 0000000000000005
> RBP: 0000000000000000 R08: 0000000120080522 R09: 0000000120080522
> R10: 0000000120080522 R11: 0000000000000293 R12: 0000000000402780
> R13: 0000000000402810 R14: 0000000000000000 R15: 0000000000000000
>
> Allocated by task 1643:
>  save_stack+0x43/0xd0 mm/kasan/kasan.c:447
>  set_track mm/kasan/kasan.c:459 [inline]
>  kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:551
>  kmem_cache_alloc_trace+0x136/0x750 mm/slab.c:3607
>  kmalloc include/linux/slab.h:516 [inline]
>  kzalloc include/linux/slab.h:705 [inline]
>  kernfs_fop_open+0x357/0xeb0 fs/kernfs/file.c:648
>  do_dentry_open+0x667/0xd40 fs/open.c:752
>  vfs_open+0x107/0x220 fs/open.c:866
>  do_last fs/namei.c:3397 [inline]
>  path_openat+0x1151/0x3530 fs/namei.c:3537
>  do_filp_open+0x25b/0x3b0 fs/namei.c:3572
>  do_sys_open+0x502/0x6d0 fs/open.c:1059
>  SYSC_open fs/open.c:1077 [inline]
>  SyS_open+0x2d/0x40 fs/open.c:1072
>  entry_SYSCALL_64_fastpath+0x1f/0x96
>
> Freed by task 1643:
>  save_stack+0x43/0xd0 mm/kasan/kasan.c:447
>  set_track mm/kasan/kasan.c:459 [inline]
>  kasan_slab_free+0x71/0xc0 mm/kasan/kasan.c:524
>  __cache_free mm/slab.c:3485 [inline]
>  kfree+0xd6/0x260 mm/slab.c:3800
>  kernfs_fop_release+0x13f/0x180 fs/kernfs/file.c:783
>  __fput+0x327/0x7e0 fs/file_table.c:209
>  ____fput+0x15/0x20 fs/file_table.c:243
>  task_work_run+0x199/0x270 kernel/task_work.c:113
>  tracehook_notify_resume include/linux/tracehook.h:191 [inline]
>  exit_to_usermode_loop+0x275/0x2f0 arch/x86/entry/common.c:165
>  prepare_exit_to_usermode arch/x86/entry/common.c:195 [inline]
>  syscall_return_slowpath+0x490/0x550 arch/x86/entry/common.c:264
>  entry_SYSCALL_64_fastpath+0x94/0x96
>
> The buggy address belongs to the object at ffff8801cb360cc0
>  which belongs to the cache kmalloc-512 of size 512
> The buggy address is located 120 bytes inside of
>  512-byte region [ffff8801cb360cc0, ffff8801cb360ec0)
> The buggy address belongs to the page:
> page:ffffea00072cd800 count:1 mapcount:0 mapping:ffff8801cb360040 index:0x0
> flags: 0x2fffc0000000100(slab)
> raw: 02fffc0000000100 ffff8801cb360040 0000000000000000 0000000100000006
> raw: ffffea00072bb6a0 ffffea00072bf720 ffff8801dac00940 0000000000000000
> page dumped because: kasan: bad access detected
>
> Memory state around the buggy address:
>  ffff8801cb360c00: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc
>  ffff8801cb360c80: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb
>>
>> ffff8801cb360d00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>
>                                         ^
>  ffff8801cb360d80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>  ffff8801cb360e00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ==================================================================
>
>
> ---
> This bug is generated by a dumb bot. It may contain errors.
> See https://goo.gl/tpsmEJ for details.
> Direct all questions to syzkaller@xxxxxxxxxxxxxxxxx
>
> syzbot will keep track of this bug report.
> If you forgot to add the Reported-by tag, once the fix for this bug is
> merged
> into any tree, please reply to this email with:
> #syz fix: exact-commit-title
> If you want to test a patch for this bug, please reply with:
> #syz test: git://repo/address.git branch
> and provide the patch inline or as an attachment.
> To mark this as a duplicate of another syzbot report, please reply with:
> #syz dup: exact-subject-of-another-report
> If it's a one-off invalid bug report, please reply with:
> #syz invalid
> Note: if the crash happens again, it will cause creation of a new bug
> report.
> Note: all commands must start from beginning of the line in the email body.

I guess skb_probe_transport_header() should be hardened to reject malicious
packets given by user space, instead of being gentle.