1. 26 4月, 2018 1 次提交
  2. 24 4月, 2018 1 次提交
  3. 13 4月, 2018 1 次提交
  4. 03 4月, 2018 1 次提交
  5. 02 4月, 2018 1 次提交
  6. 25 1月, 2018 3 次提交
  7. 06 7月, 2017 1 次提交
  8. 13 5月, 2017 1 次提交
  9. 10 5月, 2017 1 次提交
    • S
      Don't delay freeing mids when blocked on slow socket write of request · de1892b8
      Steve French 提交于
      When processing responses, and in particular freeing mids (DeleteMidQEntry),
      which is very important since it also frees the associated buffers (cifs_buf_release),
      we can block a long time if (writes to) socket is slow due to low memory or networking
      issues.
      
      We can block in send (smb request) waiting for memory, and be blocked in processing
      responess (which could free memory if we let it) - since they both grab the
      server->srv_mutex.
      
      In practice, in the DeleteMidQEntry case - there is no reason we need to
      grab the srv_mutex so remove these around DeleteMidQEntry, and it allows
      us to free memory faster.
      Signed-off-by: NSteve French <steve.french@primarydata.com>
      Acked-by: NPavel Shilovsky <pshilov@microsoft.com>
      de1892b8
  10. 28 4月, 2017 1 次提交
  11. 07 4月, 2017 1 次提交
    • S
      Handle mismatched open calls · 38bd4906
      Sachin Prabhu 提交于
      A signal can interrupt a SendReceive call which result in incoming
      responses to the call being ignored. This is a problem for calls such as
      open which results in the successful response being ignored. This
      results in an open file resource on the server.
      
      The patch looks into responses which were cancelled after being sent and
      in case of successful open closes the open fids.
      
      For this patch, the check is only done in SendReceive2()
      
      RH-bz: 1403319
      Signed-off-by: NSachin Prabhu <sprabhu@redhat.com>
      Reviewed-by: NPavel Shilovsky <pshilov@microsoft.com>
      Cc: Stable <stable@vger.kernel.org>
      38bd4906
  12. 02 2月, 2017 6 次提交
  13. 25 12月, 2016 1 次提交
  14. 01 11月, 2016 1 次提交
  15. 29 3月, 2016 1 次提交
  16. 15 1月, 2016 1 次提交
    • R
      cifs: fix race between call_async() and reconnect() · 820962dc
      Rabin Vincent 提交于
      cifs_call_async() queues the MID to the pending list and calls
      smb_send_rqst().  If smb_send_rqst() performs a partial send, it sets
      the tcpStatus to CifsNeedReconnect and returns an error code to
      cifs_call_async().  In this case, cifs_call_async() removes the MID
      from the list and returns to the caller.
      
      However, cifs_call_async() releases the server mutex _before_ removing
      the MID.  This means that a cifs_reconnect() can race with this function
      and manage to remove the MID from the list and delete the entry before
      cifs_call_async() calls cifs_delete_mid().  This leads to various
      crashes due to the use after free in cifs_delete_mid().
      
      Task1				Task2
      
      cifs_call_async():
       - rc = -EAGAIN
       - mutex_unlock(srv_mutex)
      
      				cifs_reconnect():
      				 - mutex_lock(srv_mutex)
      				 - mutex_unlock(srv_mutex)
      				 - list_delete(mid)
      				 - mid->callback()
      				 	cifs_writev_callback():
      				 		- mutex_lock(srv_mutex)
      						- delete(mid)
      				 		- mutex_unlock(srv_mutex)
      
       - cifs_delete_mid(mid) <---- use after free
      
      Fix this by removing the MID in cifs_call_async() before releasing the
      srv_mutex.  Also hold the srv_mutex in cifs_reconnect() until the MIDs
      are moved out of the pending list.
      Signed-off-by: NRabin Vincent <rabin.vincent@axis.com>
      Acked-by: NShirish Pargaonkar <shirishpargaonkar@gmail.com>
      CC: Stable <stable@vger.kernel.org>
      Signed-off-by: NSteve French <sfrench@localhost.localdomain>
      820962dc
  17. 20 8月, 2015 1 次提交
    • C
      cifs: Fix use-after-free on mid_q_entry · 5fb4e288
      Christopher Oo 提交于
      With CIFS_DEBUG_2 enabled, additional debug information is tracked inside each
      mid_q_entry struct, however cifs_save_when_sent may use the mid_q_entry after it
      has been freed from the appropriate callback if the transport layer has very low
      latency. Holding the srv_mutex fixes this use-after-free, as cifs_save_when_sent
      is called while the srv_mutex is held while the request is sent.
      Signed-off-by: NChristopher Oo <t-chriso@microsoft.com>
      5fb4e288
  18. 08 12月, 2014 1 次提交
  19. 02 8月, 2014 1 次提交
  20. 24 2月, 2014 1 次提交
  21. 03 11月, 2013 2 次提交
    • S
      cifs: Send a logoff request before removing a smb session · 7f48558e
      Shirish Pargaonkar 提交于
      Send a smb session logoff request before removing smb session off of the list.
      On a signed smb session, remvoing a session off of the list before sending
      a logoff request results in server returning an error for lack of
      smb signature.
      
      Never seen an error during smb logoff, so as per MS-SMB2 3.2.5.1,
      not sure how an error during logoff should be retried. So for now,
      if a server returns an error to a logoff request, log the error and
      remove the session off of the list.
      Signed-off-by: NShirish Pargaonkar <shirishpargaonkar@gmail.com>
      Reviewed-by: NJeff Layton <jlayton@redhat.com>
      Signed-off-by: NSteve French <smfrench@gmail.com>
      7f48558e
    • T
      cifs: Make big endian multiplex ID sequences monotonic on the wire · 3d378d3f
      Tim Gardner 提交于
      The multiplex identifier (MID) in the SMB header is only
      ever used by the client, in conjunction with PID, to match responses
      from the server. As such, the endianess of the MID is not important.
      However, When tracing packet sequences on the wire, protocol analyzers
      such as wireshark display MID as little endian. It is much more informative
      for the on-the-wire MID sequences to match debug information emitted by the
      CIFS driver.  Therefore, one should write and read MID in the SMB header
      assuming it is always little endian.
      
      Observed from wireshark during the protocol negotiation
      and session setup:
      
              Multiplex ID: 256
              Multiplex ID: 256
              Multiplex ID: 512
              Multiplex ID: 512
              Multiplex ID: 768
              Multiplex ID: 768
      
      After this patch on-the-wire MID values begin at 1 and increase monotonically.
      
      Introduce get_next_mid64() for the internal consumers that use the full 64 bit
      multiplex identifier.
      
      Introduce the helpers get_mid() and compare_mid() to make the endian
      translation clear.
      Reviewed-by: NJeff Layton <jlayton@redhat.com>
      Signed-off-by: NTim Gardner <timg@tpi.com>
      Signed-off-by: NSteve French <smfrench@gmail.com>
      3d378d3f
  22. 07 10月, 2013 1 次提交
  23. 24 6月, 2013 1 次提交
    • J
      cifs: track the enablement of signing in the TCP_Server_Info · 38d77c50
      Jeff Layton 提交于
      Currently, we determine this according to flags in the sec_mode, flags
      in the global_secflags and via other methods. That makes the semantics
      very hard to follow and there are corner cases where we don't handle
      this correctly.
      
      Add a new bool to the TCP_Server_Info that acts as a simple flag to tell
      us whether signing is enabled on this connection or not, and fix up the
      places that need to determine this to use that flag.
      
      This is a bit weird for the SMB2 case, where signing is per-session.
      SMB2 needs work in this area already though. The existing SMB2 code has
      similar logic to what we're using here, so there should be no real
      change in behavior. These changes should make it easier to implement
      per-session signing in the future though.
      Signed-off-by: NJeff Layton <jlayton@redhat.com>
      Reviewed-by: NPavel Shilovsky <piastry@etersoft.ru>
      Signed-off-by: NSteve French <smfrench@gmail.com>
      38d77c50
  24. 12 5月, 2013 1 次提交
    • C
      freezer: add unsafe versions of freezable helpers for CIFS · 5853cc2a
      Colin Cross 提交于
      CIFS calls wait_event_freezekillable_unsafe with a VFS lock held,
      which is unsafe and will cause lockdep warnings when 6aa97070
      "lockdep: check that no locks held at freeze time" is reapplied
      (it was reverted in dbf520a9).  CIFS shouldn't be doing this, but
      it has long-running syscalls that must hold a lock but also
      shouldn't block suspend.  Until CIFS freeze handling is rewritten
      to use a signal to exit out of the critical section, add a new
      wait_event_freezekillable_unsafe helper that will not run the
      lockdep test when 6aa97070 is reapplied, and call it from CIFS.
      
      In practice the likley result of holding the lock while freezing
      is that a second task blocked on the lock will never freeze,
      aborting suspend, but it is possible to manufacture a case using
      the cgroup freezer, the lock, and the suspend freezer to create
      a deadlock.  Silencing the lockdep warning here will allow
      problems to be found in other drivers that may have a more
      serious deadlock risk, and prevent new problems from being added.
      Acked-by: NPavel Machek <pavel@ucw.cz>
      Acked-by: NTejun Heo <tj@kernel.org>
      Reviewed-by: NJeff Layton <jlayton@redhat.com>
      Signed-off-by: NColin Cross <ccross@android.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      5853cc2a
  25. 05 5月, 2013 4 次提交
  26. 31 12月, 2012 1 次提交
    • J
      cifs: move check for NULL socket into smb_send_rqst · ea702b80
      Jeff Layton 提交于
      Cai reported this oops:
      
      [90701.616664] BUG: unable to handle kernel NULL pointer dereference at 0000000000000028
      [90701.625438] IP: [<ffffffff814a343e>] kernel_setsockopt+0x2e/0x60
      [90701.632167] PGD fea319067 PUD 103fda4067 PMD 0
      [90701.637255] Oops: 0000 [#1] SMP
      [90701.640878] Modules linked in: des_generic md4 nls_utf8 cifs dns_resolver binfmt_misc tun sg igb iTCO_wdt iTCO_vendor_support lpc_ich pcspkr i2c_i801 i2c_core i7core_edac edac_core ioatdma dca mfd_core coretemp kvm_intel kvm crc32c_intel microcode sr_mod cdrom ata_generic sd_mod pata_acpi crc_t10dif ata_piix libata megaraid_sas dm_mirror dm_region_hash dm_log dm_mod
      [90701.677655] CPU 10
      [90701.679808] Pid: 9627, comm: ls Tainted: G        W    3.7.1+ #10 QCI QSSC-S4R/QSSC-S4R
      [90701.688950] RIP: 0010:[<ffffffff814a343e>]  [<ffffffff814a343e>] kernel_setsockopt+0x2e/0x60
      [90701.698383] RSP: 0018:ffff88177b431bb8  EFLAGS: 00010206
      [90701.704309] RAX: ffff88177b431fd8 RBX: 00007ffffffff000 RCX: ffff88177b431bec
      [90701.712271] RDX: 0000000000000003 RSI: 0000000000000006 RDI: 0000000000000000
      [90701.720223] RBP: ffff88177b431bc8 R08: 0000000000000004 R09: 0000000000000000
      [90701.728185] R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000001
      [90701.736147] R13: ffff88184ef92000 R14: 0000000000000023 R15: ffff88177b431c88
      [90701.744109] FS:  00007fd56a1a47c0(0000) GS:ffff88105fc40000(0000) knlGS:0000000000000000
      [90701.753137] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
      [90701.759550] CR2: 0000000000000028 CR3: 000000104f15f000 CR4: 00000000000007e0
      [90701.767512] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [90701.775465] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      [90701.783428] Process ls (pid: 9627, threadinfo ffff88177b430000, task ffff88185ca4cb60)
      [90701.792261] Stack:
      [90701.794505]  0000000000000023 ffff88177b431c50 ffff88177b431c38 ffffffffa014fcb1
      [90701.802809]  ffff88184ef921bc 0000000000000000 00000001ffffffff ffff88184ef921c0
      [90701.811123]  ffff88177b431c08 ffffffff815ca3d9 ffff88177b431c18 ffff880857758000
      [90701.819433] Call Trace:
      [90701.822183]  [<ffffffffa014fcb1>] smb_send_rqst+0x71/0x1f0 [cifs]
      [90701.828991]  [<ffffffff815ca3d9>] ? schedule+0x29/0x70
      [90701.834736]  [<ffffffffa014fe6d>] smb_sendv+0x3d/0x40 [cifs]
      [90701.841062]  [<ffffffffa014fe96>] smb_send+0x26/0x30 [cifs]
      [90701.847291]  [<ffffffffa015801f>] send_nt_cancel+0x6f/0xd0 [cifs]
      [90701.854102]  [<ffffffffa015075e>] SendReceive+0x18e/0x360 [cifs]
      [90701.860814]  [<ffffffffa0134a78>] CIFSFindFirst+0x1a8/0x3f0 [cifs]
      [90701.867724]  [<ffffffffa013f731>] ? build_path_from_dentry+0xf1/0x260 [cifs]
      [90701.875601]  [<ffffffffa013f731>] ? build_path_from_dentry+0xf1/0x260 [cifs]
      [90701.883477]  [<ffffffffa01578e6>] cifs_query_dir_first+0x26/0x30 [cifs]
      [90701.890869]  [<ffffffffa015480d>] initiate_cifs_search+0xed/0x250 [cifs]
      [90701.898354]  [<ffffffff81195970>] ? fillonedir+0x100/0x100
      [90701.904486]  [<ffffffffa01554cb>] cifs_readdir+0x45b/0x8f0 [cifs]
      [90701.911288]  [<ffffffff81195970>] ? fillonedir+0x100/0x100
      [90701.917410]  [<ffffffff81195970>] ? fillonedir+0x100/0x100
      [90701.923533]  [<ffffffff81195970>] ? fillonedir+0x100/0x100
      [90701.929657]  [<ffffffff81195848>] vfs_readdir+0xb8/0xe0
      [90701.935490]  [<ffffffff81195b9f>] sys_getdents+0x8f/0x110
      [90701.941521]  [<ffffffff815d3b99>] system_call_fastpath+0x16/0x1b
      [90701.948222] Code: 66 90 55 65 48 8b 04 25 f0 c6 00 00 48 89 e5 53 48 83 ec 08 83 fe 01 48 8b 98 48 e0 ff ff 48 c7 80 48 e0 ff ff ff ff ff ff 74 22 <48> 8b 47 28 ff 50 68 65 48 8b 14 25 f0 c6 00 00 48 89 9a 48 e0
      [90701.970313] RIP  [<ffffffff814a343e>] kernel_setsockopt+0x2e/0x60
      [90701.977125]  RSP <ffff88177b431bb8>
      [90701.981018] CR2: 0000000000000028
      [90701.984809] ---[ end trace 24bd602971110a43 ]---
      
      This is likely due to a race vs. a reconnection event.
      
      The current code checks for a NULL socket in smb_send_kvec, but that's
      too late. By the time that check is done, the socket will already have
      been passed to kernel_setsockopt. Move the check into smb_send_rqst, so
      that it's checked earlier.
      
      In truth, this is a bit of a half-assed fix. The -ENOTSOCK error
      return here looks like it could bubble back up to userspace. The locking
      rules around the ssocket pointer are really unclear as well. There are
      cases where the ssocket pointer is changed without holding the srv_mutex,
      but I'm not clear whether there's a potential race here yet or not.
      
      This code seems like it could benefit from some fundamental re-think of
      how the socket handling should behave. Until then though, this patch
      should at least fix the above oops in most cases.
      
      Cc: <stable@vger.kernel.org> # 3.7+
      Reported-and-Tested-by: NCAI Qian <caiqian@redhat.com>
      Signed-off-by: NJeff Layton <jlayton@redhat.com>
      Signed-off-by: NSteve French <smfrench@gmail.com>
      ea702b80
  27. 08 10月, 2012 1 次提交
  28. 25 9月, 2012 2 次提交