1. 11 1月, 2019 1 次提交
  2. 03 1月, 2019 1 次提交
  3. 29 12月, 2018 8 次提交
  4. 24 12月, 2018 5 次提交
  5. 24 10月, 2018 5 次提交
  6. 03 10月, 2018 2 次提交
  7. 03 9月, 2018 1 次提交
  8. 10 8月, 2018 1 次提交
  9. 08 8月, 2018 4 次提交
  10. 06 7月, 2018 1 次提交
    • 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
  11. 15 6月, 2018 2 次提交
  12. 07 6月, 2018 2 次提交
  13. 03 6月, 2018 2 次提交
  14. 01 6月, 2018 2 次提交
  15. 31 5月, 2018 2 次提交
    • S
      smb3: allow "posix" mount option to enable new SMB311 protocol extensions · b326614e
      Steve French 提交于
      If "posix" (or synonym "unix" for backward compatibility) specified on mount,
      and server advertises support for SMB3.11 POSIX negotiate context, then
      enable the new posix extensions on the tcon.  This can be viewed by
      looking for "posix" in the mount options displayed by /proc/mounts
      for that mount (ie if posix extensions allowed by server and the
      experimental POSIX extensions also requested on the mount by specifying
      "posix" at mount time).
      
      Also add check to warn user if conflicting unix/nounix or posix/noposix specified
      on mount.
      Signed-off-by: NSteve French <smfrench@gmail.com>
      b326614e
    • S
      cifs: allow disabling less secure legacy dialects · f92a720e
      Steve French 提交于
      To improve security it may be helpful to have additional ways to restrict the
      ability to override the default dialects (SMB2.1, SMB3 and SMB3.02) on mount
      with old dialects (CIFS/SMB1 and SMB2) since vers=1.0 (CIFS/SMB1) and vers=2.0
      are weaker and less secure.
      
      Add a module parameter "disable_legacy_dialects"
      (/sys/module/cifs/parameters/disable_legacy_dialects) which can be set to
      1 (or equivalently Y) to forbid use of vers=1.0 or vers=2.0 on mount.
      
      Also cleans up a few build warnings about globals for various module parms.
      Signed-off-by: NSteve French <smfrench@gmail.com>
      f92a720e
  16. 28 5月, 2018 1 次提交