1. 08 8月, 2018 2 次提交
  2. 06 7月, 2018 2 次提交
    • 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
    • L
      cifs: Fix use after free of a mid_q_entry · 696e420b
      Lars Persson 提交于
      With protocol version 2.0 mounts we have seen crashes with corrupt mid
      entries. Either the server->pending_mid_q list becomes corrupt with a
      cyclic reference in one element or a mid object fetched by the
      demultiplexer thread becomes overwritten during use.
      
      Code review identified a race between the demultiplexer thread and the
      request issuing thread. The demultiplexer thread seems to be written
      with the assumption that it is the sole user of the mid object until
      it calls the mid callback which either wakes the issuer task or
      deletes the mid.
      
      This assumption is not true because the issuer task can be woken up
      earlier by a signal. If the demultiplexer thread has proceeded as far
      as setting the mid_state to MID_RESPONSE_RECEIVED then the issuer
      thread will happily end up calling cifs_delete_mid while the
      demultiplexer thread still is using the mid object.
      
      Inserting a delay in the cifs demultiplexer thread widens the race
      window and makes reproduction of the race very easy:
      
      		if (server->large_buf)
      			buf = server->bigbuf;
      
      +		usleep_range(500, 4000);
      
      		server->lstrp = jiffies;
      
      To resolve this I think the proper solution involves putting a
      reference count on the mid object. This patch makes sure that the
      demultiplexer thread holds a reference until it has finished
      processing the transaction.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NLars Persson <larper@axis.com>
      Acked-by: NPaulo Alcantara <palcantara@suse.de>
      Reviewed-by: NRonnie Sahlberg <lsahlber@redhat.com>
      Reviewed-by: NPavel Shilovsky <pshilov@microsoft.com>
      Signed-off-by: NSteve French <stfrench@microsoft.com>
      696e420b
  3. 15 6月, 2018 4 次提交
  4. 07 6月, 2018 1 次提交
  5. 03 6月, 2018 3 次提交
  6. 01 6月, 2018 1 次提交
  7. 31 5月, 2018 5 次提交
  8. 28 5月, 2018 4 次提交
  9. 13 4月, 2018 3 次提交
  10. 03 4月, 2018 2 次提交
  11. 02 4月, 2018 2 次提交
  12. 27 1月, 2018 1 次提交
    • A
      CIFS: make IPC a regular tcon · b327a717
      Aurelien Aptel 提交于
      * Remove ses->ipc_tid.
      * Make IPC$ regular tcon.
      * Add a direct pointer to it in ses->tcon_ipc.
      * Distinguish PIPE tcon from IPC tcon by adding a tcon->pipe flag. All
        IPC tcons are pipes but not all pipes are IPC.
      * All TreeConnect functions now cannot take a NULL tcon object.
      
      The IPC tcon has the same lifetime as the session it belongs to. It is
      created when the session is created and destroyed when the session is
      destroyed.
      
      Since no mounts directly refer to the IPC tcon, its refcount should
      always be set to initialisation value (1). Thus we make sure
      cifs_put_tcon() skips it.
      
      If the mount request resulting in a new session being created requires
      encryption, try to require it too for IPC.
      
      * set SERVER_NAME_LENGTH to serverName actual size
      
      The maximum length of an ipv6 string representation is defined in
      INET6_ADDRSTRLEN as 45+1 for null but lets keep what we know works.
      Signed-off-by: NAurelien Aptel <aaptel@suse.com>
      Signed-off-by: NSteve French <smfrench@gmail.com>
      Reviewed-by: NPavel Shilovsky <pshilov@microsoft.com>
      b327a717
  13. 25 1月, 2018 3 次提交
  14. 28 11月, 2017 1 次提交
    • L
      Rename superblock flags (MS_xyz -> SB_xyz) · 1751e8a6
      Linus Torvalds 提交于
      This is a pure automated search-and-replace of the internal kernel
      superblock flags.
      
      The s_flags are now called SB_*, with the names and the values for the
      moment mirroring the MS_* flags that they're equivalent to.
      
      Note how the MS_xyz flags are the ones passed to the mount system call,
      while the SB_xyz flags are what we then use in sb->s_flags.
      
      The script to do this was:
      
          # places to look in; re security/*: it generally should *not* be
          # touched (that stuff parses mount(2) arguments directly), but
          # there are two places where we really deal with superblock flags.
          FILES="drivers/mtd drivers/staging/lustre fs ipc mm \
                  include/linux/fs.h include/uapi/linux/bfs_fs.h \
                  security/apparmor/apparmorfs.c security/apparmor/include/lib.h"
          # the list of MS_... constants
          SYMS="RDONLY NOSUID NODEV NOEXEC SYNCHRONOUS REMOUNT MANDLOCK \
                DIRSYNC NOATIME NODIRATIME BIND MOVE REC VERBOSE SILENT \
                POSIXACL UNBINDABLE PRIVATE SLAVE SHARED RELATIME KERNMOUNT \
                I_VERSION STRICTATIME LAZYTIME SUBMOUNT NOREMOTELOCK NOSEC BORN \
                ACTIVE NOUSER"
      
          SED_PROG=
          for i in $SYMS; do SED_PROG="$SED_PROG -e s/MS_$i/SB_$i/g"; done
      
          # we want files that contain at least one of MS_...,
          # with fs/namespace.c and fs/pnode.c excluded.
          L=$(for i in $SYMS; do git grep -w -l MS_$i $FILES; done| sort|uniq|grep -v '^fs/namespace.c'|grep -v '^fs/pnode.c')
      
          for f in $L; do sed -i $f $SED_PROG; done
      Requested-by: NAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      1751e8a6
  15. 19 10月, 2017 1 次提交
  16. 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
  17. 05 9月, 2017 1 次提交
  18. 09 7月, 2017 2 次提交
  19. 13 5月, 2017 1 次提交