Message-Id: <20190929110502.2284-1-amade@asmblr.net>
Date:   Sun, 29 Sep 2019 13:05:00 +0200
From:   Amadeusz Sławiński <amade@...blr.net>
To:     "David S . Miller" <davem@...emloft.net>, netdev@...r.kernel.org
Cc:     Amadeusz Sławiński <amade@...blr.net>
Subject: [RFC PATCH 0/2] Incorrect memory access when using TAP

Hi,

I've recently started using virt-manager to setup my virtual machines,
along with macvtap bridge. When I start VM I noticed that following
appears in dmesg:

[  125.256517] ==================================================================
[  125.256524] BUG: KASAN: slab-out-of-bounds in sock_init_data+0x262/0x560
[  125.256525] Read of size 4 at addr ffff8887d1825a28 by task libvirtd/3749

[  125.256529] CPU: 1 PID: 3749 Comm: libvirtd Tainted: G                T 5.3.0+ #50
[  125.256530] Hardware name: ASUS All Series/SABERTOOTH Z97 MARK 2, BIOS 3503 04/18/2018
[  125.256531] Call Trace:
[  125.256535]  dump_stack+0x5b/0x88
[  125.256539]  print_address_description.constprop.0+0x19/0x210
[  125.256541]  ? sock_init_data+0x262/0x560
[  125.256543]  __kasan_report.cold+0x1a/0x40
[  125.256545]  ? sock_init_data+0x262/0x560
[  125.256547]  ? sock_init_data+0x262/0x560
[  125.256549]  kasan_report+0x2a/0x40
[  125.256551]  sock_init_data+0x262/0x560
[  125.256554]  tap_open+0x2af/0x580
[  125.256556]  chrdev_open+0x171/0x380
[  125.256558]  ? cdev_put.part.0+0x30/0x30
[  125.256561]  do_dentry_open+0x2dd/0x7f0
[  125.256562]  ? cdev_put.part.0+0x30/0x30
[  125.256564]  ? __ia32_sys_fchdir+0xe0/0xe0
[  125.256567]  ? security_inode_permission+0x56/0x70
[  125.256570]  path_openat+0x94f/0x22e0
[  125.256573]  ? preempt_count_sub+0xf/0xb0
[  125.256576]  ? __rcu_read_unlock+0x79/0x2b0
[  125.256578]  ? path_lookupat.isra.0+0x4c0/0x4c0
[  125.256581]  ? __is_insn_slot_addr+0x56/0x80
[  125.256583]  ? kernel_text_address+0xdc/0xf0
[  125.256585]  ? unwind_get_return_address+0x2d/0x40
[  125.256587]  ? profile_setup.cold+0x96/0x96
[  125.256589]  ? arch_stack_walk+0x8a/0xd0
[  125.256591]  do_filp_open+0x110/0x1a0
[  125.256593]  ? may_open_dev+0x50/0x50
[  125.256595]  ? expand_files+0x9b/0x330
[  125.256596]  ? rb_insert_color+0x32/0x3e0
[  125.256598]  ? copy_fd_bitmaps+0x110/0x110
[  125.256600]  ? preempt_count_sub+0xf/0xb0
[  125.256602]  ? _raw_spin_lock+0x82/0xd0
[  125.256604]  ? preempt_count_sub+0xf/0xb0
[  125.256605]  ? _raw_spin_unlock+0x19/0x30
[  125.256607]  ? __alloc_fd+0x110/0x270
[  125.256609]  do_sys_open+0x1fb/0x2f0
[  125.256610]  ? filp_open+0x50/0x50
[  125.256613]  do_syscall_64+0x5e/0x190
[  125.256615]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[  125.256617] RIP: 0033:0x73dc99750972
[  125.256619] Code: 00 00 85 c0 74 95 44 89 54 24 0c e8 48 f2 ff ff 44 8b 54 24 0c 44 89 e2 48 89 ee 41 89 c0 bf 9c ff ff ff b8 01 01 00 00 0f 05 <48> 3d 00 f0 ff ff 77 2c 44 89 c7 89 44 24 0c e8 7a f2 ff ff 8b 44
[  125.256620] RSP: 002b:000073dc837fd230 EFLAGS: 00000293 ORIG_RAX: 0000000000000101
[  125.256622] RAX: ffffffffffffffda RBX: 000073dc837fd340 RCX: 000073dc99750972
[  125.256623] RDX: 0000000000000002 RSI: 000073dc7401e430 RDI: 00000000ffffff9c
[  125.256624] RBP: 000073dc7401e430 R08: 0000000000000000 R09: 000073dc7401b300
[  125.256625] R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000002
[  125.256626] R13: 000073dc7401ee60 R14: 000000000000000a R15: 000073dc3c09a910

[  125.256629] Allocated by task 3749:
[  125.256630]  save_stack+0x20/0x80
[  125.256632]  __kasan_kmalloc.constprop.0+0xc3/0xd0
[  125.256633]  __kmalloc+0x151/0x2e0
[  125.256635]  sk_prot_alloc+0x10b/0x1c0
[  125.256636]  sk_alloc+0x2b/0x370
[  125.256637]  tap_open+0x11c/0x580
[  125.256639]  chrdev_open+0x171/0x380
[  125.256640]  do_dentry_open+0x2dd/0x7f0
[  125.256641]  path_openat+0x94f/0x22e0
[  125.256642]  do_filp_open+0x110/0x1a0
[  125.256644]  do_sys_open+0x1fb/0x2f0
[  125.256645]  do_syscall_64+0x5e/0x190
[  125.256646]  entry_SYSCALL_64_after_hwframe+0x44/0xa9

[  125.256647] Freed by task 4309:
[  125.256649]  save_stack+0x20/0x80
[  125.256650]  __kasan_slab_free+0x12c/0x170
[  125.256651]  kfree+0xa5/0x230
[  125.256653]  alloc_iova_fast+0x2bb/0x380
[  125.256656]  intel_alloc_iova+0xad/0xc0
[  125.256657]  intel_map_sg+0xe0/0x210
[  125.256659]  ata_qc_issue+0x4aa/0x4c0
[  125.256661]  ata_scsi_translate+0x1b0/0x2c0
[  125.256663]  ata_scsi_queuecmd+0x13f/0x400
[  125.256664]  scsi_queue_rq+0xbed/0xf00
[  125.256667]  __blk_mq_try_issue_directly+0x263/0x380
[  125.256668]  blk_mq_try_issue_directly+0x81/0xf0
[  125.256670]  blk_mq_make_request+0x5fe/0x770
[  125.256672]  generic_make_request+0x176/0x530
[  125.256673]  submit_bio+0x9f/0x260
[  125.256676]  submit_bh_wbc+0x348/0x380
[  125.256677]  ll_rw_block+0x123/0x130
[  125.256679]  __breadahead+0x91/0xe0
[  125.256681]  __ext4_get_inode_loc+0x65e/0x720
[  125.256682]  __ext4_iget+0x1ff/0x1980
[  125.256684]  ext4_lookup+0x21a/0x380
[  125.256686]  path_openat+0xae2/0x22e0
[  125.256687]  do_filp_open+0x110/0x1a0
[  125.256688]  do_sys_open+0x1fb/0x2f0
[  125.256689]  do_syscall_64+0x5e/0x190
[  125.256690]  entry_SYSCALL_64_after_hwframe+0x44/0xa9

[  125.256692] The buggy address belongs to the object at ffff8887d1825468
                which belongs to the cache kmalloc-2k of size 2048
[  125.256694] The buggy address is located 1472 bytes inside of
                2048-byte region [ffff8887d1825468, ffff8887d1825c68)
[  125.256694] The buggy address belongs to the page:
[  125.256696] page:ffffea001f460800 refcount:1 mapcount:0 mapping:ffff8887db0113c0 index:0x0 compound_mapcount: 0
[  125.256698] flags: 0x200000000010200(slab|head)
[  125.256701] raw: 0200000000010200 ffffea001d55a008 ffff8887db003470 ffff8887db0113c0
[  125.256703] raw: 0000000000000000 00000000000d000d 00000001ffffffff 0000000000000000
[  125.256703] page dumped because: kasan: bad access detected

[  125.256704] Memory state around the buggy address:
[  125.256706]  ffff8887d1825900: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[  125.256707]  ffff8887d1825980: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[  125.256708] >ffff8887d1825a00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[  125.256709]                                   ^
[  125.256710]  ffff8887d1825a80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[  125.256712]  ffff8887d1825b00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[  125.256712] ==================================================================
[  125.256713] Disabling lock debugging due to kernel taint

>From my investigation it happen because of:
		sk->sk_uid	=	SOCK_INODE(sock)->i_uid;
in sock_init_data().

>From this it seems quite obvious that sock_init_data() actually expects
passed  sock  argument to be allocated with sock_alloc.

Following patches are attempt to fix this by using sock_alloc(), it
seems to work fine on my system, but I'm not that well versed on
networking internals.

Few points of doubt:
 * TAP & TUN apparently just need, sock without inode, so doing
sock_alloc doesn't seem that good
 * As far as I understand an API I should put sock_release somewhere,
but if I put it in places that seem logical to me it causes oops on null
pointer, does network API free scoket automatically somewhere?
 * Maybe it is just simpler and more error proof to add some flag inside
sock_alloc, so it knows that it can do SOCK_INODE call...

Cheers,
Amadeusz


Amadeusz Sławiński (2):
  net: tap: Fix incorrect memory access
  net: tun: Fix incorrect memory access

 drivers/net/tap.c      | 34 ++++++++++------
 drivers/net/tun.c      | 92 +++++++++++++++++++++++-------------------
 include/linux/if_tap.h |  2 +-
 3 files changed, 72 insertions(+), 56 deletions(-)

-- 
2.23.0

Powered by blists - more mailing lists