1. 29 10月, 2019 2 次提交
  2. 18 10月, 2019 4 次提交
    • D
      cifs: use cifsInodeInfo->open_file_lock while iterating to avoid a panic · a8de7090
      Dave Wysochanski 提交于
      commit cb248819d209d113e45fed459773991518e8e80b upstream.
      
      Commit 487317c99477 ("cifs: add spinlock for the openFileList to
      cifsInodeInfo") added cifsInodeInfo->open_file_lock spin_lock to protect
      the openFileList, but missed a few places where cifs_inode->openFileList
      was enumerated.  Change these remaining tcon->open_file_lock to
      cifsInodeInfo->open_file_lock to avoid panic in is_size_safe_to_change.
      
      [17313.245641] RIP: 0010:is_size_safe_to_change+0x57/0xb0 [cifs]
      [17313.245645] Code: 68 40 48 89 ef e8 19 67 b7 f1 48 8b 43 40 48 8d 4b 40 48 8d 50 f0 48 39 c1 75 0f eb 47 48 8b 42 10 48 8d 50 f0 48 39 c1 74 3a <8b> 80 88 00 00 00 83 c0 01 a8 02 74 e6 48 89 ef c6 07 00 0f 1f 40
      [17313.245649] RSP: 0018:ffff94ae1baefa30 EFLAGS: 00010202
      [17313.245654] RAX: dead000000000100 RBX: ffff88dc72243300 RCX: ffff88dc72243340
      [17313.245657] RDX: dead0000000000f0 RSI: 00000000098f7940 RDI: ffff88dd3102f040
      [17313.245659] RBP: ffff88dd3102f040 R08: 0000000000000000 R09: ffff94ae1baefc40
      [17313.245661] R10: ffffcdc8bb1c4e80 R11: ffffcdc8b50adb08 R12: 00000000098f7940
      [17313.245663] R13: ffff88dc72243300 R14: ffff88dbc8f19600 R15: ffff88dc72243428
      [17313.245667] FS:  00007fb145485700(0000) GS:ffff88dd3e000000(0000) knlGS:0000000000000000
      [17313.245670] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [17313.245672] CR2: 0000026bb46c6000 CR3: 0000004edb110003 CR4: 00000000007606e0
      [17313.245753] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [17313.245756] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      [17313.245759] PKRU: 55555554
      [17313.245761] Call Trace:
      [17313.245803]  cifs_fattr_to_inode+0x16b/0x580 [cifs]
      [17313.245838]  cifs_get_inode_info+0x35c/0xa60 [cifs]
      [17313.245852]  ? kmem_cache_alloc_trace+0x151/0x1d0
      [17313.245885]  cifs_open+0x38f/0x990 [cifs]
      [17313.245921]  ? cifs_revalidate_dentry_attr+0x3e/0x350 [cifs]
      [17313.245953]  ? cifsFileInfo_get+0x30/0x30 [cifs]
      [17313.245960]  ? do_dentry_open+0x132/0x330
      [17313.245963]  do_dentry_open+0x132/0x330
      [17313.245969]  path_openat+0x573/0x14d0
      [17313.245974]  do_filp_open+0x93/0x100
      [17313.245979]  ? __check_object_size+0xa3/0x181
      [17313.245986]  ? audit_alloc_name+0x7e/0xd0
      [17313.245992]  do_sys_open+0x184/0x220
      [17313.245999]  do_syscall_64+0x5b/0x1b0
      
      Fixes: 487317c99477 ("cifs: add spinlock for the openFileList to cifsInodeInfo")
      CC: Stable <stable@vger.kernel.org>
      Signed-off-by: NDave Wysochanski <dwysocha@redhat.com>
      Reviewed-by: NRonnie Sahlberg <lsahlber@redhat.com>
      Signed-off-by: NSteve French <stfrench@microsoft.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a8de7090
    • P
      CIFS: Force reval dentry if LOOKUP_REVAL flag is set · 230b339a
      Pavel Shilovsky 提交于
      commit 0b3d0ef9840f7be202393ca9116b857f6f793715 upstream.
      
      Mark inode for force revalidation if LOOKUP_REVAL flag is set.
      This tells the client to actually send a QueryInfo request to
      the server to obtain the latest metadata in case a directory
      or a file were changed remotely. Only do that if the client
      doesn't have a lease for the file to avoid unneeded round
      trips to the server.
      
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NPavel Shilovsky <pshilov@microsoft.com>
      Signed-off-by: NSteve French <stfrench@microsoft.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      230b339a
    • P
      CIFS: Force revalidate inode when dentry is stale · 0bc78de4
      Pavel Shilovsky 提交于
      commit c82e5ac7fe3570a269c0929bf7899f62048e7dbc upstream.
      
      Currently the client indicates that a dentry is stale when inode
      numbers or type types between a local inode and a remote file
      don't match. If this is the case attributes is not being copied
      from remote to local, so, it is already known that the local copy
      has stale metadata. That's why the inode needs to be marked for
      revalidation in order to tell the VFS to lookup the dentry again
      before openning a file. This prevents unexpected stale errors
      to be returned to the user space when openning a file.
      
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NPavel Shilovsky <pshilov@microsoft.com>
      Signed-off-by: NSteve French <stfrench@microsoft.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0bc78de4
    • P
      CIFS: Gracefully handle QueryInfo errors during open · d72c2115
      Pavel Shilovsky 提交于
      commit 30573a82fb179420b8aac30a3a3595aa96a93156 upstream.
      
      Currently if the client identifies problems when processing
      metadata returned in CREATE response, the open handle is being
      leaked. This causes multiple problems like a file missing a lease
      break by that client which causes high latencies to other clients
      accessing the file. Another side-effect of this is that the file
      can't be deleted.
      
      Fix this by closing the file after the client hits an error after
      the file was opened and the open descriptor wasn't returned to
      the user space. Also convert -ESTALE to -EOPENSTALE to allow
      the VFS to revalidate a dentry and retry the open.
      
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NPavel Shilovsky <pshilov@microsoft.com>
      Signed-off-by: NSteve French <stfrench@microsoft.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d72c2115
  3. 05 10月, 2019 3 次提交
  4. 01 10月, 2019 1 次提交
  5. 21 9月, 2019 2 次提交
  6. 16 9月, 2019 6 次提交
  7. 29 8月, 2019 2 次提交
  8. 16 8月, 2019 2 次提交
  9. 07 8月, 2019 1 次提交
  10. 25 6月, 2019 1 次提交
  11. 09 6月, 2019 2 次提交
  12. 26 5月, 2019 1 次提交
  13. 02 5月, 2019 2 次提交
  14. 27 4月, 2019 4 次提交
  15. 20 4月, 2019 2 次提交
    • S
      cifs: fallback to older infolevels on findfirst queryinfo retry · e9603cff
      Steve French 提交于
      [ Upstream commit 3b7960caceafdfc2cdfe2850487f8d091eb41144 ]
      
      In cases where queryinfo fails, we have cases in cifs (vers=1.0)
      where with backupuid mounts we retry the query info with findfirst.
      This doesn't work to some NetApp servers which don't support
      WindowsXP (and later) infolevel 261 (SMB_FIND_FILE_ID_FULL_DIR_INFO)
      so in this case use other info levels (in this case it will usually
      be level 257, SMB_FIND_FILE_DIRECTORY_INFO).
      
      (Also fixes some indentation)
      
      See kernel bugzilla 201435
      Signed-off-by: NSteve French <stfrench@microsoft.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      e9603cff
    • S
      fix incorrect error code mapping for OBJECTID_NOT_FOUND · 40276e4e
      Steve French 提交于
      [ Upstream commit 85f9987b236cf46e06ffdb5c225cf1f3c0acb789 ]
      
      It was mapped to EIO which can be confusing when user space
      queries for an object GUID for an object for which the server
      file system doesn't support (or hasn't saved one).
      
      As Amir Goldstein suggested this is similar to ENOATTR
      (equivalently ENODATA in Linux errno definitions) so
      changing NT STATUS code mapping for OBJECTID_NOT_FOUND
      to ENODATA.
      Signed-off-by: NSteve French <stfrench@microsoft.com>
      CC: Amir Goldstein <amir73il@gmail.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      40276e4e
  16. 06 4月, 2019 4 次提交
    • Y
      cifs: Fix NULL pointer dereference of devname · 36a3219e
      Yao Liu 提交于
      [ Upstream commit 68e2672f8fbd1e04982b8d2798dd318bf2515dd2 ]
      
      There is a NULL pointer dereference of devname in strspn()
      
      The oops looks something like:
      
        CIFS: Attempting to mount (null)
        BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
        ...
        RIP: 0010:strspn+0x0/0x50
        ...
        Call Trace:
         ? cifs_parse_mount_options+0x222/0x1710 [cifs]
         ? cifs_get_volume_info+0x2f/0x80 [cifs]
         cifs_setup_volume_info+0x20/0x190 [cifs]
         cifs_get_volume_info+0x50/0x80 [cifs]
         cifs_smb3_do_mount+0x59/0x630 [cifs]
         ? ida_alloc_range+0x34b/0x3d0
         cifs_do_mount+0x11/0x20 [cifs]
         mount_fs+0x52/0x170
         vfs_kern_mount+0x6b/0x170
         do_mount+0x216/0xdc0
         ksys_mount+0x83/0xd0
         __x64_sys_mount+0x25/0x30
         do_syscall_64+0x65/0x220
         entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      Fix this by adding a NULL check on devname in cifs_parse_devname()
      Signed-off-by: NYao Liu <yotta.liu@ucloud.cn>
      Signed-off-by: NSteve French <stfrench@microsoft.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      36a3219e
    • N
      cifs: Accept validate negotiate if server return NT_STATUS_NOT_SUPPORTED · d579b4ea
      Namjae Jeon 提交于
      [ Upstream commit 969ae8e8d4ee54c99134d3895f2adf96047f5bee ]
      
      Old windows version or Netapp SMB server will return
      NT_STATUS_NOT_SUPPORTED since they do not allow or implement
      FSCTL_VALIDATE_NEGOTIATE_INFO. The client should accept the response
      provided it's properly signed.
      
      See
      https://blogs.msdn.microsoft.com/openspecification/2012/06/28/smb3-secure-dialect-negotiation/
      
      and
      
      MS-SMB2 validate negotiate response processing:
      https://msdn.microsoft.com/en-us/library/hh880630.aspx
      
      Samba client had already handled it.
      https://bugzilla.samba.org/attachment.cgi?id=13285&action=editSigned-off-by: NNamjae Jeon <linkinjeon@gmail.com>
      Signed-off-by: NSteve French <stfrench@microsoft.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      d579b4ea
    • L
      cifs: use correct format characters · 626d98bb
      Louis Taylor 提交于
      [ Upstream commit 259594bea574e515a148171b5cd84ce5cbdc028a ]
      
      When compiling with -Wformat, clang emits the following warnings:
      
      fs/cifs/smb1ops.c:312:20: warning: format specifies type 'unsigned
      short' but the argument has type 'unsigned int' [-Wformat]
                               tgt_total_cnt, total_in_tgt);
                                              ^~~~~~~~~~~~
      
      fs/cifs/cifs_dfs_ref.c:289:4: warning: format specifies type 'short'
      but the argument has type 'int' [-Wformat]
                       ref->flags, ref->server_type);
                       ^~~~~~~~~~
      
      fs/cifs/cifs_dfs_ref.c:289:16: warning: format specifies type 'short'
      but the argument has type 'int' [-Wformat]
                       ref->flags, ref->server_type);
                                   ^~~~~~~~~~~~~~~~
      
      fs/cifs/cifs_dfs_ref.c:291:4: warning: format specifies type 'short'
      but the argument has type 'int' [-Wformat]
                       ref->ref_flag, ref->path_consumed);
                       ^~~~~~~~~~~~~
      
      fs/cifs/cifs_dfs_ref.c:291:19: warning: format specifies type 'short'
      but the argument has type 'int' [-Wformat]
                       ref->ref_flag, ref->path_consumed);
                                      ^~~~~~~~~~~~~~~~~~
      The types of these arguments are unconditionally defined, so this patch
      updates the format character to the correct ones for ints and unsigned
      ints.
      
      Link: https://github.com/ClangBuiltLinux/linux/issues/378Signed-off-by: NLouis Taylor <louis@kragniz.eu>
      Signed-off-by: NSteve French <stfrench@microsoft.com>
      Reviewed-by: NNick Desaulniers <ndesaulniers@google.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      626d98bb
    • A
      CIFS: fix POSIX lock leak and invalid ptr deref · 2938651d
      Aurelien Aptel 提交于
      [ Upstream commit bc31d0cdcfbadb6258b45db97e93b1c83822ba33 ]
      
      We have a customer reporting crashes in lock_get_status() with many
      "Leaked POSIX lock" messages preceeding the crash.
      
       Leaked POSIX lock on dev=0x0:0x56 ...
       Leaked POSIX lock on dev=0x0:0x56 ...
       Leaked POSIX lock on dev=0x0:0x56 ...
       Leaked POSIX lock on dev=0x0:0x53 ...
       Leaked POSIX lock on dev=0x0:0x53 ...
       Leaked POSIX lock on dev=0x0:0x53 ...
       Leaked POSIX lock on dev=0x0:0x53 ...
       POSIX: fl_owner=ffff8900e7b79380 fl_flags=0x1 fl_type=0x1 fl_pid=20709
       Leaked POSIX lock on dev=0x0:0x4b ino...
       Leaked locks on dev=0x0:0x4b ino=0xf911400000029:
       POSIX: fl_owner=ffff89f41c870e00 fl_flags=0x1 fl_type=0x1 fl_pid=19592
       stack segment: 0000 [#1] SMP
       Modules linked in: binfmt_misc msr tcp_diag udp_diag inet_diag unix_diag af_packet_diag netlink_diag rpcsec_gss_krb5 arc4 ecb auth_rpcgss nfsv4 md4 nfs nls_utf8 lockd grace cifs sunrpc ccm dns_resolver fscache af_packet iscsi_ibft iscsi_boot_sysfs vmw_vsock_vmci_transport vsock xfs libcrc32c sb_edac edac_core crct10dif_pclmul crc32_pclmul ghash_clmulni_intel drbg ansi_cprng vmw_balloon aesni_intel aes_x86_64 lrw gf128mul glue_helper ablk_helper cryptd joydev pcspkr vmxnet3 i2c_piix4 vmw_vmci shpchp fjes processor button ac btrfs xor raid6_pq sr_mod cdrom ata_generic sd_mod ata_piix vmwgfx crc32c_intel drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm serio_raw ahci libahci drm libata vmw_pvscsi sg dm_multipath dm_mod scsi_dh_rdac scsi_dh_emc scsi_dh_alua scsi_mod autofs4
      
       Supported: Yes
       CPU: 6 PID: 28250 Comm: lsof Not tainted 4.4.156-94.64-default #1
       Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 04/05/2016
       task: ffff88a345f28740 ti: ffff88c74005c000 task.ti: ffff88c74005c000
       RIP: 0010:[<ffffffff8125dcab>]  [<ffffffff8125dcab>] lock_get_status+0x9b/0x3b0
       RSP: 0018:ffff88c74005fd90  EFLAGS: 00010202
       RAX: ffff89bde83e20ae RBX: ffff89e870003d18 RCX: 0000000049534f50
       RDX: ffffffff81a3541f RSI: ffffffff81a3544e RDI: ffff89bde83e20ae
       RBP: 0026252423222120 R08: 0000000020584953 R09: 000000000000ffff
       R10: 0000000000000000 R11: ffff88c74005fc70 R12: ffff89e5ca7b1340
       R13: 00000000000050e5 R14: ffff89e870003d30 R15: ffff89e5ca7b1340
       FS:  00007fafd64be800(0000) GS:ffff89f41fd00000(0000) knlGS:0000000000000000
       CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
       CR2: 0000000001c80018 CR3: 000000a522048000 CR4: 0000000000360670
       DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
       DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
       Stack:
        0000000000000208 ffffffff81a3d6b6 ffff89e870003d30 ffff89e870003d18
        ffff89e5ca7b1340 ffff89f41738d7c0 ffff89e870003d30 ffff89e5ca7b1340
        ffffffff8125e08f 0000000000000000 ffff89bc22b67d00 ffff88c74005ff28
       Call Trace:
        [<ffffffff8125e08f>] locks_show+0x2f/0x70
        [<ffffffff81230ad1>] seq_read+0x251/0x3a0
        [<ffffffff81275bbc>] proc_reg_read+0x3c/0x70
        [<ffffffff8120e456>] __vfs_read+0x26/0x140
        [<ffffffff8120e9da>] vfs_read+0x7a/0x120
        [<ffffffff8120faf2>] SyS_read+0x42/0xa0
        [<ffffffff8161cbc3>] entry_SYSCALL_64_fastpath+0x1e/0xb7
      
      When Linux closes a FD (close(), close-on-exec, dup2(), ...) it calls
      filp_close() which also removes all posix locks.
      
      The lock struct is initialized like so in filp_close() and passed
      down to cifs
      
      	...
              lock.fl_type = F_UNLCK;
              lock.fl_flags = FL_POSIX | FL_CLOSE;
              lock.fl_start = 0;
              lock.fl_end = OFFSET_MAX;
      	...
      
      Note the FL_CLOSE flag, which hints the VFS code that this unlocking
      is done for closing the fd.
      
      filp_close()
        locks_remove_posix(filp, id);
          vfs_lock_file(filp, F_SETLK, &lock, NULL);
            return filp->f_op->lock(filp, cmd, fl) => cifs_lock()
              rc = cifs_setlk(file, flock, type, wait_flag, posix_lck, lock, unlock, xid);
                rc = server->ops->mand_unlock_range(cfile, flock, xid);
                if (flock->fl_flags & FL_POSIX && !rc)
                        rc = locks_lock_file_wait(file, flock)
      
      Notice how we don't call locks_lock_file_wait() which does the
      generic VFS lock/unlock/wait work on the inode if rc != 0.
      
      If we are closing the handle, the SMB server is supposed to remove any
      locks associated with it. Similarly, cifs.ko frees and wakes up any
      lock and lock waiter when closing the file:
      
      cifs_close()
        cifsFileInfo_put(file->private_data)
      	/*
      	 * Delete any outstanding lock records. We'll lose them when the file
      	 * is closed anyway.
      	 */
      	down_write(&cifsi->lock_sem);
      	list_for_each_entry_safe(li, tmp, &cifs_file->llist->locks, llist) {
      		list_del(&li->llist);
      		cifs_del_lock_waiters(li);
      		kfree(li);
      	}
      	list_del(&cifs_file->llist->llist);
      	kfree(cifs_file->llist);
      	up_write(&cifsi->lock_sem);
      
      So we can safely ignore unlocking failures in cifs_lock() if they
      happen with the FL_CLOSE flag hint set as both the server and the
      client take care of it during the actual closing.
      
      This is not a proper fix for the unlocking failure but it's safe and
      it seems to prevent the lock leakages and crashes the customer
      experiences.
      Signed-off-by: NAurelien Aptel <aaptel@suse.com>
      Signed-off-by: NNeilBrown <neil@brown.name>
      Signed-off-by: NSteve French <stfrench@microsoft.com>
      Acked-by: NPavel Shilovsky <pshilov@microsoft.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      2938651d
  17. 27 3月, 2019 1 次提交
    • S
      SMB3: Fix SMB3.1.1 guest mounts to Samba · 38bd575b
      Steve French 提交于
      commit 8c11a607d1d9cd6e7f01fd6b03923597fb0ef95a upstream.
      
      Workaround problem with Samba responses to SMB3.1.1
      null user (guest) mounts.  The server doesn't set the
      expected flag in the session setup response so we have
      to do a similar check to what is done in smb3_validate_negotiate
      where we also check if the user is a null user (but not sec=krb5
      since username might not be passed in on mount for Kerberos case).
      
      Note that the commit below tightened the conditions and forced signing
      for the SMB2-TreeConnect commands as per MS-SMB2.
      However, this should only apply to normal user sessions and not for
      cases where there is no user (even if server forgets to set the flag
      in the response) since we don't have anything useful to sign with.
      This is especially important now that the more secure SMB3.1.1 protocol
      is in the default dialect list.
      
      An earlier patch ("cifs: allow guest mounts to work for smb3.11") fixed
      the guest mounts to Windows.
      
          Fixes: 6188f28b ("Tree connect for SMB3.1.1 must be signed for non-encrypted shares")
      Reviewed-by: NRonnie Sahlberg <lsahlber@redhat.com>
      Reviewed-by: NPaulo Alcantara <palcantara@suse.de>
      CC: Stable <stable@vger.kernel.org>
      Signed-off-by: NSteve French <stfrench@microsoft.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      38bd575b