1. 10 5月, 2019 2 次提交
  2. 08 5月, 2019 29 次提交
  3. 02 5月, 2019 1 次提交
  4. 25 4月, 2019 4 次提交
    • E
      crypto: shash - remove shash_desc::flags · 877b5691
      Eric Biggers 提交于
      The flags field in 'struct shash_desc' never actually does anything.
      The only ostensibly supported flag is CRYPTO_TFM_REQ_MAY_SLEEP.
      However, no shash algorithm ever sleeps, making this flag a no-op.
      
      With this being the case, inevitably some users who can't sleep wrongly
      pass MAY_SLEEP.  These would all need to be fixed if any shash algorithm
      actually started sleeping.  For example, the shash_ahash_*() functions,
      which wrap a shash algorithm with the ahash API, pass through MAY_SLEEP
      from the ahash API to the shash API.  However, the shash functions are
      called under kmap_atomic(), so actually they're assumed to never sleep.
      
      Even if it turns out that some users do need preemption points while
      hashing large buffers, we could easily provide a helper function
      crypto_shash_update_large() which divides the data into smaller chunks
      and calls crypto_shash_update() and cond_resched() for each chunk.  It's
      not necessary to have a flag in 'struct shash_desc', nor is it necessary
      to make individual shash algorithms aware of this at all.
      
      Therefore, remove shash_desc::flags, and document that the
      crypto_shash_*() functions can be called from any context.
      Signed-off-by: NEric Biggers <ebiggers@google.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      877b5691
    • J
      cifs: fix page reference leak with readv/writev · 13f5938d
      Jérôme Glisse 提交于
      CIFS can leak pages reference gotten through GUP (get_user_pages*()
      through iov_iter_get_pages()). This happen if cifs_send_async_read()
      or cifs_write_from_iter() calls fail from within __cifs_readv() and
      __cifs_writev() respectively. This patch move page unreference to
      cifs_aio_ctx_release() which will happens on all code paths this is
      all simpler to follow for correctness.
      Signed-off-by: NJérôme Glisse <jglisse@redhat.com>
      Cc: Steve French <sfrench@samba.org>
      Cc: linux-cifs@vger.kernel.org
      Cc: samba-technical@lists.samba.org
      Cc: Alexander Viro <viro@zeniv.linux.org.uk>
      Cc: linux-fsdevel@vger.kernel.org
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Stable <stable@vger.kernel.org>
      Signed-off-by: NSteve French <stfrench@microsoft.com>
      Reviewed-by: NPavel Shilovsky <pshilov@microsoft.com>
      13f5938d
    • F
      cifs: do not attempt cifs operation on smb2+ rename error · 652727bb
      Frank Sorenson 提交于
      A path-based rename returning EBUSY will incorrectly try opening
      the file with a cifs (NT Create AndX) operation on an smb2+ mount,
      which causes the server to force a session close.
      
      If the mount is smb2+, skip the fallback.
      Signed-off-by: NFrank Sorenson <sorenson@redhat.com>
      Signed-off-by: NSteve French <stfrench@microsoft.com>
      CC: Stable <stable@vger.kernel.org>
      Reviewed-by: NRonnie Sahlberg <lsahlber@redhat.com>
      652727bb
    • R
      cifs: fix memory leak in SMB2_read · 05fd5c2c
      Ronnie Sahlberg 提交于
      Commit 088aaf17 introduced a leak where
      if SMB2_read() returned an error we would return without freeing the
      request buffer.
      
      Cc: Stable <stable@vger.kernel.org>
      Signed-off-by: NRonnie Sahlberg <lsahlber@redhat.com>
      Reviewed-by: NPavel Shilovsky <pshilov@microsoft.com>
      Signed-off-by: NSteve French <stfrench@microsoft.com>
      05fd5c2c
  5. 16 4月, 2019 4 次提交
    • A
      CIFS: keep FileInfo handle live during oplock break · b98749ca
      Aurelien Aptel 提交于
      In the oplock break handler, writing pending changes from pages puts
      the FileInfo handle. If the refcount reaches zero it closes the handle
      and waits for any oplock break handler to return, thus causing a deadlock.
      
      To prevent this situation:
      
      * We add a wait flag to cifsFileInfo_put() to decide whether we should
        wait for running/pending oplock break handlers
      
      * We keep an additionnal reference of the SMB FileInfo handle so that
        for the rest of the handler putting the handle won't close it.
        - The ref is bumped everytime we queue the handler via the
          cifs_queue_oplock_break() helper.
        - The ref is decremented at the end of the handler
      
      This bug was triggered by xfstest 464.
      
      Also important fix to address the various reports of
      oops in smb2_push_mandatory_locks
      Signed-off-by: NAurelien Aptel <aaptel@suse.com>
      Signed-off-by: NSteve French <stfrench@microsoft.com>
      Reviewed-by: NPavel Shilovsky <pshilov@microsoft.com>
      CC: Stable <stable@vger.kernel.org>
      b98749ca
    • R
      cifs: fix handle leak in smb2_query_symlink() · e6d0fb7b
      Ronnie Sahlberg 提交于
      If we enter smb2_query_symlink() for something that is not a symlink
      and where the SMB2_open() would succeed we would never end up
      closing this handle and would thus leak a handle on the server.
      
      Fix this by immediately calling SMB2_close() on successfull open.
      Signed-off-by: NRonnie Sahlberg <lsahlber@redhat.com>
      CC: Stable <stable@vger.kernel.org>
      Signed-off-by: NSteve French <stfrench@microsoft.com>
      Reviewed-by: NPavel Shilovsky <pshilov@microsoft.com>
      e6d0fb7b
    • Z
      cifs: Fix lease buffer length error · b57a55e2
      ZhangXiaoxu 提交于
      There is a KASAN slab-out-of-bounds:
      BUG: KASAN: slab-out-of-bounds in _copy_from_iter_full+0x783/0xaa0
      Read of size 80 at addr ffff88810c35e180 by task mount.cifs/539
      
      CPU: 1 PID: 539 Comm: mount.cifs Not tainted 4.19 #10
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
                  rel-1.12.0-0-ga698c8995f-prebuilt.qemu.org 04/01/2014
      Call Trace:
       dump_stack+0xdd/0x12a
       print_address_description+0xa7/0x540
       kasan_report+0x1ff/0x550
       check_memory_region+0x2f1/0x310
       memcpy+0x2f/0x80
       _copy_from_iter_full+0x783/0xaa0
       tcp_sendmsg_locked+0x1840/0x4140
       tcp_sendmsg+0x37/0x60
       inet_sendmsg+0x18c/0x490
       sock_sendmsg+0xae/0x130
       smb_send_kvec+0x29c/0x520
       __smb_send_rqst+0x3ef/0xc60
       smb_send_rqst+0x25a/0x2e0
       compound_send_recv+0x9e8/0x2af0
       cifs_send_recv+0x24/0x30
       SMB2_open+0x35e/0x1620
       open_shroot+0x27b/0x490
       smb2_open_op_close+0x4e1/0x590
       smb2_query_path_info+0x2ac/0x650
       cifs_get_inode_info+0x1058/0x28f0
       cifs_root_iget+0x3bb/0xf80
       cifs_smb3_do_mount+0xe00/0x14c0
       cifs_do_mount+0x15/0x20
       mount_fs+0x5e/0x290
       vfs_kern_mount+0x88/0x460
       do_mount+0x398/0x31e0
       ksys_mount+0xc6/0x150
       __x64_sys_mount+0xea/0x190
       do_syscall_64+0x122/0x590
       entry_SYSCALL_64_after_hwframe+0x44/0xa9
      
      It can be reproduced by the following step:
        1. samba configured with: server max protocol = SMB2_10
        2. mount -o vers=default
      
      When parse the mount version parameter, the 'ops' and 'vals'
      was setted to smb30,  if negotiate result is smb21, just
      update the 'ops' to smb21, but the 'vals' is still smb30.
      When add lease context, the iov_base is allocated with smb21
      ops, but the iov_len is initiallited with the smb30. Because
      the iov_len is longer than iov_base, when send the message,
      copy array out of bounds.
      
      we need to keep the 'ops' and 'vals' consistent.
      
      Fixes: 9764c02f ("SMB3: Add support for multidialect negotiate (SMB2.1 and later)")
      Fixes: d5c7076b ("smb3: add smb3.1.1 to default dialect list")
      Signed-off-by: NZhangXiaoxu <zhangxiaoxu5@huawei.com>
      Signed-off-by: NSteve French <stfrench@microsoft.com>
      CC: Stable <stable@vger.kernel.org>
      Reviewed-by: NPavel Shilovsky <pshilov@microsoft.com>
      b57a55e2
    • Z
      cifs: Fix use-after-free in SMB2_read · 088aaf17
      ZhangXiaoxu 提交于
      There is a KASAN use-after-free:
      BUG: KASAN: use-after-free in SMB2_read+0x1136/0x1190
      Read of size 8 at addr ffff8880b4e45e50 by task ln/1009
      
      Should not release the 'req' because it will use in the trace.
      
      Fixes: eccb4422 ("smb3: Add ftrace tracepoints for improved SMB3 debugging")
      Signed-off-by: NZhangXiaoxu <zhangxiaoxu5@huawei.com>
      Signed-off-by: NSteve French <stfrench@microsoft.com>
      CC: Stable <stable@vger.kernel.org> 4.18+
      Reviewed-by: NPavel Shilovsky <pshilov@microsoft.com>
      088aaf17