1. 08 8月, 2018 1 次提交
  2. 06 7月, 2018 1 次提交
    • 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
  3. 15 6月, 2018 1 次提交
  4. 01 6月, 2018 3 次提交
  5. 31 5月, 2018 2 次提交
  6. 24 4月, 2018 1 次提交
  7. 13 4月, 2018 2 次提交
  8. 03 4月, 2018 1 次提交
  9. 02 4月, 2018 1 次提交
  10. 07 2月, 2018 1 次提交
  11. 27 1月, 2018 1 次提交
  12. 25 1月, 2018 17 次提交
  13. 19 10月, 2017 2 次提交
  14. 18 9月, 2017 1 次提交
    • S
      SMB3: Add support for multidialect negotiate (SMB2.1 and later) · 9764c02f
      Steve French 提交于
      With the need to discourage use of less secure dialect, SMB1 (CIFS),
      we temporarily upgraded the dialect to SMB3 in 4.13, but since there
      are various servers which only support SMB2.1 (2.1 is more secure
      than CIFS/SMB1) but not optimal for a default dialect - add support
      for multidialect negotiation.  cifs.ko will now request SMB2.1
      or later (ie SMB2.1 or SMB3.0, SMB3.02) and the server will
      pick the latest most secure one it can support.
      
      In addition since we are sending multidialect negotiate, add
      support for secure negotiate to validate that a man in the
      middle didn't downgrade us.
      Signed-off-by: NSteve French <smfrench@gmail.com>
      Reviewed-by: NPavel Shilovsky <pshilov@microsoft.com>
      CC: Stable <stable@vger.kernel.org> # 4.13+
      9764c02f
  15. 05 9月, 2017 1 次提交
  16. 31 8月, 2017 1 次提交
  17. 03 3月, 2017 1 次提交
  18. 02 2月, 2017 2 次提交