1. 10 8月, 2018 2 次提交
  2. 09 8月, 2018 3 次提交
  3. 08 8月, 2018 31 次提交
  4. 06 7月, 2018 4 次提交
    • S
      cifs: Fix stack out-of-bounds in smb{2,3}_create_lease_buf() · 729c0c9d
      Stefano Brivio 提交于
      smb{2,3}_create_lease_buf() store a lease key in the lease
      context for later usage on a lease break.
      
      In most paths, the key is currently sourced from data that
      happens to be on the stack near local variables for oplock in
      SMB2_open() callers, e.g. from open_shroot(), whereas
      smb2_open_file() properly allocates space on its stack for it.
      
      The address of those local variables holding the oplock is then
      passed to create_lease_buf handlers via SMB2_open(), and 16
      bytes near oplock are used. This causes a stack out-of-bounds
      access as reported by KASAN on SMB2.1 and SMB3 mounts (first
      out-of-bounds access is shown here):
      
      [  111.528823] BUG: KASAN: stack-out-of-bounds in smb3_create_lease_buf+0x399/0x3b0 [cifs]
      [  111.530815] Read of size 8 at addr ffff88010829f249 by task mount.cifs/985
      [  111.532838] CPU: 3 PID: 985 Comm: mount.cifs Not tainted 4.18.0-rc3+ #91
      [  111.534656] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1 04/01/2014
      [  111.536838] Call Trace:
      [  111.537528]  dump_stack+0xc2/0x16b
      [  111.540890]  print_address_description+0x6a/0x270
      [  111.542185]  kasan_report+0x258/0x380
      [  111.544701]  smb3_create_lease_buf+0x399/0x3b0 [cifs]
      [  111.546134]  SMB2_open+0x1ef8/0x4b70 [cifs]
      [  111.575883]  open_shroot+0x339/0x550 [cifs]
      [  111.591969]  smb3_qfs_tcon+0x32c/0x1e60 [cifs]
      [  111.617405]  cifs_mount+0x4f3/0x2fc0 [cifs]
      [  111.674332]  cifs_smb3_do_mount+0x263/0xf10 [cifs]
      [  111.677915]  mount_fs+0x55/0x2b0
      [  111.679504]  vfs_kern_mount.part.22+0xaa/0x430
      [  111.684511]  do_mount+0xc40/0x2660
      [  111.698301]  ksys_mount+0x80/0xd0
      [  111.701541]  do_syscall_64+0x14e/0x4b0
      [  111.711807]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
      [  111.713665] RIP: 0033:0x7f372385b5fa
      [  111.715311] Code: 48 8b 0d 99 78 2c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 49 89 ca b8 a5 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 66 78 2c 00 f7 d8 64 89 01 48
      [  111.720330] RSP: 002b:00007ffff27049d8 EFLAGS: 00000206 ORIG_RAX: 00000000000000a5
      [  111.722601] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f372385b5fa
      [  111.724842] RDX: 000055c2ecdc73b2 RSI: 000055c2ecdc73f9 RDI: 00007ffff270580f
      [  111.727083] RBP: 00007ffff2705804 R08: 000055c2ee976060 R09: 0000000000001000
      [  111.729319] R10: 0000000000000000 R11: 0000000000000206 R12: 00007f3723f4d000
      [  111.731615] R13: 000055c2ee976060 R14: 00007f3723f4f90f R15: 0000000000000000
      
      [  111.735448] The buggy address belongs to the page:
      [  111.737420] page:ffffea000420a7c0 count:0 mapcount:0 mapping:0000000000000000 index:0x0
      [  111.739890] flags: 0x17ffffc0000000()
      [  111.741750] raw: 0017ffffc0000000 0000000000000000 dead000000000200 0000000000000000
      [  111.744216] raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000
      [  111.746679] page dumped because: kasan: bad access detected
      
      [  111.750482] Memory state around the buggy address:
      [  111.752562]  ffff88010829f100: 00 f2 f2 f2 f2 f2 f2 f2 00 00 00 00 00 00 00 00
      [  111.754991]  ffff88010829f180: 00 00 f2 f2 00 00 00 00 00 00 00 00 00 00 00 00
      [  111.757401] >ffff88010829f200: 00 00 00 00 00 f1 f1 f1 f1 01 f2 f2 f2 f2 f2 f2
      [  111.759801]                                               ^
      [  111.762034]  ffff88010829f280: f2 02 f2 f2 f2 f2 f2 f2 f2 00 00 00 00 00 00 00
      [  111.764486]  ffff88010829f300: f2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      [  111.766913] ==================================================================
      
      Lease keys are however already generated and stored in fid data
      on open and create paths: pass them down to the lease context
      creation handlers and use them.
      Suggested-by: NAurélien Aptel <aaptel@suse.com>
      Reviewed-by: NAurelien Aptel <aaptel@suse.com>
      Fixes: b8c32dbb ("CIFS: Request SMB2.1 leases")
      Signed-off-by: NStefano Brivio <sbrivio@redhat.com>
      Signed-off-by: NSteve French <stfrench@microsoft.com>
      729c0c9d
    • P
      cifs: Fix infinite loop when using hard mount option · 7ffbe655
      Paulo Alcantara 提交于
      For every request we send, whether it is SMB1 or SMB2+, we attempt to
      reconnect tcon (cifs_reconnect_tcon or smb2_reconnect) before carrying
      out the request.
      
      So, while server->tcpStatus != CifsNeedReconnect, we wait for the
      reconnection to succeed on wait_event_interruptible_timeout(). If it
      returns, that means that either the condition was evaluated to true, or
      timeout elapsed, or it was interrupted by a signal.
      
      Since we're not handling the case where the process woke up due to a
      received signal (-ERESTARTSYS), the next call to
      wait_event_interruptible_timeout() will _always_ fail and we end up
      looping forever inside either cifs_reconnect_tcon() or smb2_reconnect().
      
      Here's an example of how to trigger that:
      
      $ mount.cifs //foo/share /mnt/test -o
      username=foo,password=foo,vers=1.0,hard
      
      (break connection to server before executing bellow cmd)
      $ stat -f /mnt/test & sleep 140
      [1] 2511
      
      $ ps -aux -q 2511
      USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
      root      2511  0.0  0.0  12892  1008 pts/0    S    12:24   0:00 stat -f
      /mnt/test
      
      $ kill -9 2511
      
      (wait for a while; process is stuck in the kernel)
      $ ps -aux -q 2511
      USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
      root      2511 83.2  0.0  12892  1008 pts/0    R    12:24  30:01 stat -f
      /mnt/test
      
      By using 'hard' mount point means that cifs.ko will keep retrying
      indefinitely, however we must allow the process to be killed otherwise
      it would hang the system.
      Signed-off-by: NPaulo Alcantara <palcantara@suse.de>
      Cc: stable@vger.kernel.org
      Reviewed-by: NAurelien Aptel <aaptel@suse.com>
      Signed-off-by: NSteve French <stfrench@microsoft.com>
      7ffbe655
    • S
      cifs: Fix slab-out-of-bounds in send_set_info() on SMB2 ACE setting · f46ecbd9
      Stefano Brivio 提交于
      A "small" CIFS buffer is not big enough in general to hold a
      setacl request for SMB2, and we end up overflowing the buffer in
      send_set_info(). For instance:
      
       # mount.cifs //127.0.0.1/test /mnt/test -o username=test,password=test,nounix,cifsacl
       # touch /mnt/test/acltest
       # getcifsacl /mnt/test/acltest
       REVISION:0x1
       CONTROL:0x9004
       OWNER:S-1-5-21-2926364953-924364008-418108241-1000
       GROUP:S-1-22-2-1001
       ACL:S-1-5-21-2926364953-924364008-418108241-1000:ALLOWED/0x0/0x1e01ff
       ACL:S-1-22-2-1001:ALLOWED/0x0/R
       ACL:S-1-22-2-1001:ALLOWED/0x0/R
       ACL:S-1-5-21-2926364953-924364008-418108241-1000:ALLOWED/0x0/0x1e01ff
       ACL:S-1-1-0:ALLOWED/0x0/R
       # setcifsacl -a "ACL:S-1-22-2-1004:ALLOWED/0x0/R" /mnt/test/acltest
      
      this setacl will cause the following KASAN splat:
      
      [  330.777927] BUG: KASAN: slab-out-of-bounds in send_set_info+0x4dd/0xc20 [cifs]
      [  330.779696] Write of size 696 at addr ffff88010d5e2860 by task setcifsacl/1012
      
      [  330.781882] CPU: 1 PID: 1012 Comm: setcifsacl Not tainted 4.18.0-rc2+ #2
      [  330.783140] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1 04/01/2014
      [  330.784395] Call Trace:
      [  330.784789]  dump_stack+0xc2/0x16b
      [  330.786777]  print_address_description+0x6a/0x270
      [  330.787520]  kasan_report+0x258/0x380
      [  330.788845]  memcpy+0x34/0x50
      [  330.789369]  send_set_info+0x4dd/0xc20 [cifs]
      [  330.799511]  SMB2_set_acl+0x76/0xa0 [cifs]
      [  330.801395]  set_smb2_acl+0x7ac/0xf30 [cifs]
      [  330.830888]  cifs_xattr_set+0x963/0xe40 [cifs]
      [  330.840367]  __vfs_setxattr+0x84/0xb0
      [  330.842060]  __vfs_setxattr_noperm+0xe6/0x370
      [  330.843848]  vfs_setxattr+0xc2/0xd0
      [  330.845519]  setxattr+0x258/0x320
      [  330.859211]  path_setxattr+0x15b/0x1b0
      [  330.864392]  __x64_sys_setxattr+0xc0/0x160
      [  330.866133]  do_syscall_64+0x14e/0x4b0
      [  330.876631]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
      [  330.878503] RIP: 0033:0x7ff2e507db0a
      [  330.880151] Code: 48 8b 0d 89 93 2c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 49 89 ca b8 bc 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 56 93 2c 00 f7 d8 64 89 01 48
      [  330.885358] RSP: 002b:00007ffdc4903c18 EFLAGS: 00000246 ORIG_RAX: 00000000000000bc
      [  330.887733] RAX: ffffffffffffffda RBX: 000055d1170de140 RCX: 00007ff2e507db0a
      [  330.890067] RDX: 000055d1170de7d0 RSI: 000055d115b39184 RDI: 00007ffdc4904818
      [  330.892410] RBP: 0000000000000001 R08: 0000000000000000 R09: 000055d1170de7e4
      [  330.894785] R10: 00000000000002b8 R11: 0000000000000246 R12: 0000000000000007
      [  330.897148] R13: 000055d1170de0c0 R14: 0000000000000008 R15: 000055d1170de550
      
      [  330.901057] Allocated by task 1012:
      [  330.902888]  kasan_kmalloc+0xa0/0xd0
      [  330.904714]  kmem_cache_alloc+0xc8/0x1d0
      [  330.906615]  mempool_alloc+0x11e/0x380
      [  330.908496]  cifs_small_buf_get+0x35/0x60 [cifs]
      [  330.910510]  smb2_plain_req_init+0x4a/0xd60 [cifs]
      [  330.912551]  send_set_info+0x198/0xc20 [cifs]
      [  330.914535]  SMB2_set_acl+0x76/0xa0 [cifs]
      [  330.916465]  set_smb2_acl+0x7ac/0xf30 [cifs]
      [  330.918453]  cifs_xattr_set+0x963/0xe40 [cifs]
      [  330.920426]  __vfs_setxattr+0x84/0xb0
      [  330.922284]  __vfs_setxattr_noperm+0xe6/0x370
      [  330.924213]  vfs_setxattr+0xc2/0xd0
      [  330.926008]  setxattr+0x258/0x320
      [  330.927762]  path_setxattr+0x15b/0x1b0
      [  330.929592]  __x64_sys_setxattr+0xc0/0x160
      [  330.931459]  do_syscall_64+0x14e/0x4b0
      [  330.933314]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
      
      [  330.936843] Freed by task 0:
      [  330.938588] (stack is not available)
      
      [  330.941886] The buggy address belongs to the object at ffff88010d5e2800
       which belongs to the cache cifs_small_rq of size 448
      [  330.946362] The buggy address is located 96 bytes inside of
       448-byte region [ffff88010d5e2800, ffff88010d5e29c0)
      [  330.950722] The buggy address belongs to the page:
      [  330.952789] page:ffffea0004357880 count:1 mapcount:0 mapping:ffff880108fdca80 index:0x0 compound_mapcount: 0
      [  330.955665] flags: 0x17ffffc0008100(slab|head)
      [  330.957760] raw: 0017ffffc0008100 dead000000000100 dead000000000200 ffff880108fdca80
      [  330.960356] raw: 0000000000000000 0000000080100010 00000001ffffffff 0000000000000000
      [  330.963005] page dumped because: kasan: bad access detected
      
      [  330.967039] Memory state around the buggy address:
      [  330.969255]  ffff88010d5e2880: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      [  330.971833]  ffff88010d5e2900: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      [  330.974397] >ffff88010d5e2980: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc
      [  330.976956]                                            ^
      [  330.979226]  ffff88010d5e2a00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      [  330.981755]  ffff88010d5e2a80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      [  330.984225] ==================================================================
      
      Fix this by allocating a regular CIFS buffer in
      smb2_plain_req_init() if the request command is SMB2_SET_INFO.
      Reported-by: NJianhong Yin <jiyin@redhat.com>
      Fixes: 366ed846 ("cifs: Use smb 2 - 3 and cifsacl mount options setacl function")
      CC: Stable <stable@vger.kernel.org>
      Signed-off-by: NStefano Brivio <sbrivio@redhat.com>
      Reviewed-and-tested-by: NAurelien Aptel <aaptel@suse.com>
      Signed-off-by: NSteve French <stfrench@microsoft.com>
      f46ecbd9
    • P
      cifs: Fix memory leak in smb2_set_ea() · 6aa0c114
      Paulo Alcantara 提交于
      This patch fixes a memory leak when doing a setxattr(2) in SMB2+.
      Signed-off-by: NPaulo Alcantara <palcantara@suse.de>
      Cc: stable@vger.kernel.org
      Signed-off-by: NSteve French <stfrench@microsoft.com>
      Reviewed-by: NAurelien Aptel <aaptel@suse.com>
      6aa0c114