1. 13 Dec, 2018 1 commit
  2. 27 Nov, 2018 1 commit
  3. 13 Nov, 2018 3 commits
  4. 10 Nov, 2018 1 commit
  5. 10 Oct, 2018 4 commits
    • Aurelien Aptel's avatar
      smb2: fix missing files in root share directory listing · 57539911
      Aurelien Aptel authored
      commit 0595751f267994c3c7027377058e4185b3a28e75 upstream.
      When mounting a Windows share that is the root of a drive (eg. C$)
      the server does not return . and .. directory entries. This results in
      the smb2 code path erroneously skipping the 2 first entries.
      Pseudo-code of the readdir() code path:
      cifs_readdir(struct file, struct dir_context)
          initiate_cifs_search            <-- if no reponse cached yet
              dir_emit                    <-- adds "." and ".." if we're at pos=0
              initiate_cifs_search        <-- if pos < start of current response
                                               (restart search)
              server->ops->query_dir_next <-- if pos > end of current response
                                               (fetch next search res)
          for(...)                        <-- loops over cur response entries
                                                starting at pos
              cifs_filldir                <-- skip . and .., emit entry
      A) dir_emit_dots() always adds . & ..
         and sets the current dir pos to 2 (0 and 1 are done).
      Therefore we always want the index_to_find to be 2 regardless of if
      the response has . and ..
      B) smb1 code initializes index_of_last_entry with a +2 offset
        in cifssmb.c CIFSFindFirst():
      		psrch_inf->index_of_last_entry = 2 /* skip . and .. */ +
      Later in find_cifs_entry() we want to find the next dir entry at pos=2
      as a result of (A)
      	first_entry_in_buffer = cfile->srch_inf.index_of_last_entry -
      This var is the dir pos that the first entry in the buffer will
      have therefore it must be 2 in the first call.
      If we don't offset index_of_last_entry by 2 (like in (B)),
      first_entry_in_buffer=0 but we were instructed to get pos=2 so this
      code in find_cifs_entry() skips the 2 first which is ok for non-root
      shares, as it skips . and .. from the response but is not ok for root
      shares where the 2 first are actual files
      		pos_in_buf = index_to_find - first_entry_in_buffer;
                      // pos_in_buf=2
      		// we skip 2 first response entries :(
      		for (i = 0; (i < (pos_in_buf)) && (cur_ent != NULL); i++) {
      			/* go entry by entry figuring out which is first */
      			cur_ent = nxt_dir_entry(cur_ent, end_of_smb,
      C) cifs_filldir() skips . and .. so we can safely ignore them for now.
      Sample program:
      int main(int argc, char **argv)
      	const char *path = argc >= 2 ? argv[1] : ".";
      	DIR *dh;
      	struct dirent *de;
      	printf("listing path <%s>\n", path);
      	dh = opendir(path);
      	if (!dh) {
      		printf("opendir error %d\n", errno);
      		return 1;
      	while (1) {
      		de = readdir(dh);
      		if (!de) {
      			if (errno) {
      				printf("readdir error %d\n", errno);
      				return 1;
      			printf("end of listing\n");
      		printf("off=%lu <%s>\n", de->d_off, de->d_name);
      	return 0;
      Before the fix with SMB1 on root shares:
      <.>            off=1
      <..>           off=2
      <$Recycle.Bin> off=3
      <bootmgr>      off=4
      and on non-root shares:
      <.>    off=1
      <..>   off=4  <-- after adding .., the offsets jumps to +2 because
      <2536> off=5       we skipped . and .. from response buffer (C)
      <411>  off=6       but still incremented pos
      <file> off=7
      <fsx>  off=8
      Therefore the fix for smb2 is to mimic smb1 behaviour and offset the
      index_of_last_entry by 2.
      Test results comparing smb1 and smb2 before/after the fix on root
      share, non-root shares and on large directories (ie. multi-response
      dir listing):
      PRE FIX
      pre-1-root VS pre-2-root:
              ERR pre-2-root is missing [bootmgr, $Recycle.Bin]
      pre-1-nonroot VS pre-2-nonroot:
              OK~ same files, same order, different offsets
      pre-1-nonroot-large VS pre-2-nonroot-large:
              OK~ same files, same order, different offsets
      POST FIX
      post-1-root VS post-2-root:
              OK same files, same order, same offsets
      post-1-nonroot VS post-2-nonroot:
              OK same files, same order, same offsets
      post-1-nonroot-large VS post-2-nonroot-large:
              OK same files, same order, same offsets
      pre-1-root VS post-1-root:
              OK same files, same order, same offsets
      pre-1-nonroot VS post-1-nonroot:
              OK same files, same order, same offsets
      BugLink: https://bugzilla.samba.org/show_bug.cgi?id=13107Signed-off-by: default avatarAurelien Aptel <aaptel@suse.com>
      Signed-off-by: default avatarPaulo Alcantara <palcantara@suse.deR>
      Reviewed-by: default avatarRonnie Sahlberg <lsahlber@redhat.com>
      Signed-off-by: default avatarSteve French <stfrench@microsoft.com>
      CC: Stable <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Dan Carpenter's avatar
      cifs: read overflow in is_valid_oplock_break() · 3466db7b
      Dan Carpenter authored
      [ Upstream commit 097f5863b1a0c9901f180bbd56ae7d630655faaa ]
      We need to verify that the "data_offset" is within bounds.
      Reported-by: default avatarDr Silvio Cesare of InfoSect <silvio.cesare@gmail.com>
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarSteve French <stfrench@microsoft.com>
      Reviewed-by: default avatarAurelien Aptel <aaptel@suse.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Stephen Rothwell's avatar
      fs/cifs: suppress a string overflow warning · 7a0ee61d
      Stephen Rothwell authored
      [ Upstream commit bcfb84a996f6fa90b5e6e2954b2accb7a4711097 ]
      A powerpc build of cifs with gcc v8.2.0 produces this warning:
      fs/cifs/cifssmb.c: In function ‘CIFSSMBNegotiate’:
      fs/cifs/cifssmb.c:605:3: warning: ‘strncpy’ writing 16 bytes into a region of size 1 overflows the destination [-Wstringop-overflow=]
         strncpy(pSMB->DialectsArray+count, protocols[i].name, 16);
      Since we are already doing a strlen() on the source, change the strncpy
      to a memcpy().
      Signed-off-by: default avatarStephen Rothwell <sfr@canb.auug.org.au>
      Signed-off-by: default avatarSteve French <stfrench@microsoft.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Jon Kuhn's avatar
      fs/cifs: don't translate SFM_SLASH (U+F026) to backslash · 34acac49
      Jon Kuhn authored
      [ Upstream commit c15e3f19a6d5c89b1209dc94b40e568177cb0921 ]
      When a Mac client saves an item containing a backslash to a file server
      the backslash is represented in the CIFS/SMB protocol as as U+F026.
      Before this change, listing a directory containing an item with a
      backslash in its name will return that item with the backslash
      represented with a true backslash character (U+005C) because
      convert_sfm_character mapped U+F026 to U+005C when interpretting the
      CIFS/SMB protocol response.  However, attempting to open or stat the
      path using a true backslash will result in an error because
      convert_to_sfm_char does not map U+005C back to U+F026 causing the
      CIFS/SMB request to be made with the backslash represented as U+005C.
      This change simply prevents the U+F026 to U+005C conversion from
      happenning.  This is analogous to how the code does not do any
      translation of UNI_SLASH (U+F000).
      Signed-off-by: default avatarJon Kuhn <jkuhn@barracuda.com>
      Signed-off-by: default avatarSteve French <stfrench@microsoft.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  6. 26 Sep, 2018 2 commits
  7. 15 Sep, 2018 3 commits
  8. 05 Sep, 2018 5 commits
  9. 11 Jul, 2018 1 commit
    • Paulo Alcantara's avatar
      cifs: Fix infinite loop when using hard mount option · 2c4f6b71
      Paulo Alcantara authored
      commit 7ffbe65578b44fafdef577a360eb0583929f7c6e upstream.
      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
      (break connection to server before executing bellow cmd)
      $ stat -f /mnt/test & sleep 140
      [1] 2511
      $ ps -aux -q 2511
      root      2511  0.0  0.0  12892  1008 pts/0    S    12:24   0:00 stat -f
      $ kill -9 2511
      (wait for a while; process is stuck in the kernel)
      $ ps -aux -q 2511
      root      2511 83.2  0.0  12892  1008 pts/0    R    12:24  30:01 stat -f
      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: default avatarPaulo Alcantara <palcantara@suse.de>
      Cc: stable@vger.kernel.org
      Reviewed-by: default avatarAurelien Aptel <aaptel@suse.com>
      Signed-off-by: default avatarSteve French <stfrench@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  10. 26 Jun, 2018 1 commit
  11. 30 May, 2018 1 commit
  12. 29 Apr, 2018 1 commit
  13. 24 Apr, 2018 1 commit
  14. 13 Apr, 2018 2 commits
    • Christophe JAILLET's avatar
      SMB2: Fix share type handling · cfea563e
      Christophe JAILLET authored
      [ Upstream commit cd123007 ]
      In fs/cifs/smb2pdu.h, we have:
      #define SMB2_SHARE_TYPE_DISK    0x01
      #define SMB2_SHARE_TYPE_PIPE    0x02
      #define SMB2_SHARE_TYPE_PRINT   0x03
      Knowing that, with the current code, the SMB2_SHARE_TYPE_PRINT case can
      never trigger and printer share would be interpreted as disk share.
      So, test the ShareType value for equality instead.
      Fixes: faaf946a ("CIFS: Add tree connect/disconnect capability for SMB2")
      Signed-off-by: default avatarChristophe JAILLET <christophe.jaillet@wanadoo.fr>
      Acked-by: default avatarAurelien Aptel <aaptel@suse.com>
      Signed-off-by: default avatarSteve French <smfrench@gmail.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Rabin Vincent's avatar
      CIFS: silence lockdep splat in cifs_relock_file() · 6ed24ef4
      Rabin Vincent authored
      [ Upstream commit 560d3889 ]
      cifs_relock_file() can perform a down_write() on the inode's lock_sem even
      though it was already performed in cifs_strict_readv().  Lockdep complains
      about this.  AFAICS, there is no problem here, and lockdep just needs to be
      told that this nesting is OK.
       [ INFO: possible recursive locking detected ]
       4.11.0+ #20 Not tainted
       cat/701 is trying to acquire lock:
        (&cifsi->lock_sem){++++.+}, at: cifs_reopen_file+0x7a7/0xc00
       but task is already holding lock:
        (&cifsi->lock_sem){++++.+}, at: cifs_strict_readv+0x177/0x310
       other info that might help us debug this:
        Possible unsafe locking scenario:
        *** DEADLOCK ***
        May be due to missing lock nesting notation
       1 lock held by cat/701:
        #0:  (&cifsi->lock_sem){++++.+}, at: cifs_strict_readv+0x177/0x310
       stack backtrace:
       CPU: 0 PID: 701 Comm: cat Not tainted 4.11.0+ #20
       Call Trace:
        ? trace_hardirqs_on_thunk+0x1a/0x1c
        ? preempt_schedule_irq+0x6b/0x80
        ? lock_acquire+0xcc/0x260
        ? cifs_reopen_file+0x7a7/0xc00
        ? cifs_reopen_file+0x7a7/0xc00
        ? printk+0x43/0x4b
        ? generic_pipe_buf_nosteal+0x10/0x10
      Signed-off-by: default avatarRabin Vincent <rabinv@axis.com>
      Acked-by: default avatarPavel Shilovsky <pshilov@microsoft.com>
      Signed-off-by: default avatarSteve French <smfrench@gmail.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  15. 24 Mar, 2018 3 commits
  16. 17 Feb, 2018 3 commits
  17. 08 Nov, 2017 1 commit
  18. 18 Oct, 2017 1 commit
  19. 05 Oct, 2017 5 commits