20 Oct, 2020

1 commit


17 Apr, 2020

1 commit


08 Apr, 2020

1 commit

  • CIFS uses pre-allocated crypto structures to calculate signatures for both
    incoming and outgoing packets. In this way it doesn't need to allocate crypto
    structures for every packet, but it requires a lock to prevent concurrent
    access to crypto structures.

    Remove the lock by allocating crypto structures on the fly for
    incoming packets. At the same time, we can still use pre-allocated crypto
    structures for outgoing packets, as they are already protected by transport
    lock srv_mutex.

    Signed-off-by: Long Li
    Signed-off-by: Steve French

    Long Li
     

30 Mar, 2020

1 commit


28 Mar, 2020

1 commit


07 Feb, 2020

1 commit

  • The server var was accidentally used as an iterator over the global
    list of connections, thus overwritten the passed argument. This
    resulted in the wrong signing key being returned for extra channels.

    Fix this by using a separate var to iterate.

    Signed-off-by: Aurelien Aptel
    Signed-off-by: Steve French
    Reviewed-by: Paulo Alcantara (SUSE)
    Reviewed-by: Pavel Shilovsky

    Aurelien Aptel
     

27 Jan, 2020

1 commit

  • The task which created the MID may be gone by the time cifsd attempts to
    call the callbacks on MIDs from cifs_reconnect().

    This leads to a use-after-free of the task struct in cifs_wake_up_task:

    ==================================================================
    BUG: KASAN: use-after-free in __lock_acquire+0x31a0/0x3270
    Read of size 8 at addr ffff8880103e3a68 by task cifsd/630

    CPU: 0 PID: 630 Comm: cifsd Not tainted 5.5.0-rc6+ #119
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1 04/01/2014
    Call Trace:
    dump_stack+0x8e/0xcb
    print_address_description.constprop.5+0x1d3/0x3c0
    ? __lock_acquire+0x31a0/0x3270
    __kasan_report+0x152/0x1aa
    ? __lock_acquire+0x31a0/0x3270
    ? __lock_acquire+0x31a0/0x3270
    kasan_report+0xe/0x20
    __lock_acquire+0x31a0/0x3270
    ? __wake_up_common+0x1dc/0x630
    ? _raw_spin_unlock_irqrestore+0x4c/0x60
    ? mark_held_locks+0xf0/0xf0
    ? _raw_spin_unlock_irqrestore+0x39/0x60
    ? __wake_up_common_lock+0xd5/0x130
    ? __wake_up_common+0x630/0x630
    lock_acquire+0x13f/0x330
    ? try_to_wake_up+0xa3/0x19e0
    _raw_spin_lock_irqsave+0x38/0x50
    ? try_to_wake_up+0xa3/0x19e0
    try_to_wake_up+0xa3/0x19e0
    ? cifs_compound_callback+0x178/0x210
    ? set_cpus_allowed_ptr+0x10/0x10
    cifs_reconnect+0xa1c/0x15d0
    ? generic_ip_connect+0x1860/0x1860
    ? rwlock_bug.part.0+0x90/0x90
    cifs_readv_from_socket+0x479/0x690
    cifs_read_from_socket+0x9d/0xe0
    ? cifs_readv_from_socket+0x690/0x690
    ? mempool_resize+0x690/0x690
    ? rwlock_bug.part.0+0x90/0x90
    ? memset+0x1f/0x40
    ? allocate_buffers+0xff/0x340
    cifs_demultiplex_thread+0x388/0x2a50
    ? cifs_handle_standard+0x610/0x610
    ? rcu_read_lock_held_common+0x120/0x120
    ? mark_lock+0x11b/0xc00
    ? __lock_acquire+0x14ed/0x3270
    ? __kthread_parkme+0x78/0x100
    ? lockdep_hardirqs_on+0x3e8/0x560
    ? lock_downgrade+0x6a0/0x6a0
    ? lockdep_hardirqs_on+0x3e8/0x560
    ? _raw_spin_unlock_irqrestore+0x39/0x60
    ? cifs_handle_standard+0x610/0x610
    kthread+0x2bb/0x3a0
    ? kthread_create_worker_on_cpu+0xc0/0xc0
    ret_from_fork+0x3a/0x50

    Allocated by task 649:
    save_stack+0x19/0x70
    __kasan_kmalloc.constprop.5+0xa6/0xf0
    kmem_cache_alloc+0x107/0x320
    copy_process+0x17bc/0x5370
    _do_fork+0x103/0xbf0
    __x64_sys_clone+0x168/0x1e0
    do_syscall_64+0x9b/0xec0
    entry_SYSCALL_64_after_hwframe+0x49/0xbe

    Freed by task 0:
    save_stack+0x19/0x70
    __kasan_slab_free+0x11d/0x160
    kmem_cache_free+0xb5/0x3d0
    rcu_core+0x52f/0x1230
    __do_softirq+0x24d/0x962

    The buggy address belongs to the object at ffff8880103e32c0
    which belongs to the cache task_struct of size 6016
    The buggy address is located 1960 bytes inside of
    6016-byte region [ffff8880103e32c0, ffff8880103e4a40)
    The buggy address belongs to the page:
    page:ffffea000040f800 refcount:1 mapcount:0 mapping:ffff8880108da5c0
    index:0xffff8880103e4c00 compound_mapcount: 0
    raw: 4000000000010200 ffffea00001f2208 ffffea00001e3408 ffff8880108da5c0
    raw: ffff8880103e4c00 0000000000050003 00000001ffffffff 0000000000000000
    page dumped because: kasan: bad access detected

    Memory state around the buggy address:
    ffff8880103e3900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
    ffff8880103e3980: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
    >ffff8880103e3a00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
    ^
    ffff8880103e3a80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
    ffff8880103e3b00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
    ==================================================================

    This can be reliably reproduced by adding the below delay to
    cifs_reconnect(), running find(1) on the mount, restarting the samba
    server while find is running, and killing find during the delay:

    spin_unlock(&GlobalMid_Lock);
    mutex_unlock(&server->srv_mutex);

    + msleep(10000);
    +
    cifs_dbg(FYI, "%s: issuing mid callbacks\n", __func__);
    list_for_each_safe(tmp, tmp2, &retry_list) {
    mid_entry = list_entry(tmp, struct mid_q_entry, qhead);

    Fix this by holding a reference to the task struct until the MID is
    freed.

    Signed-off-by: Vincent Whitchurch
    Signed-off-by: Steve French
    CC: Stable
    Reviewed-by: Paulo Alcantara (SUSE)
    Reviewed-by: Pavel Shilovsky

    Vincent Whitchurch
     

25 Nov, 2019

3 commits

  • Update signing key of first channel whenever generating the master
    sigining/encryption/decryption keys rather than only in cifs_mount().

    This also fixes reconnect when re-establishing smb sessions to other
    servers.

    Signed-off-by: Paulo Alcantara (SUSE)
    Reviewed-by: Aurelien Aptel
    Signed-off-by: Steve French

    Paulo Alcantara (SUSE)
     
  • After doing mount() successfully we call cifs_try_adding_channels()
    which will open as many channels as it can.

    Channels are closed when the master session is closed.

    The master connection becomes the first channel.

    ,-------------> global cifs_tcp_ses_list
    Signed-off-by: Steve French

    Aurelien Aptel
     
  • As we get down to the transport layer, plenty of functions are passed
    the session pointer and assume the transport to use is ses->server.

    Instead we modify those functions to pass (ses, server) so that we
    can decouple the session from the server.

    Signed-off-by: Aurelien Aptel
    Signed-off-by: Steve French

    Aurelien Aptel
     

17 Sep, 2019

2 commits

  • Add new mount option "signloosely" which enables signing but skips the
    sometimes expensive signing checks in the responses (signatures are
    calculated and sent correctly in the SMB2/SMB3 requests even with this
    mount option but skipped in the responses). Although weaker for security
    (and also data integrity in case a packet were corrupted), this can provide
    enough of a performance benefit (calculating the signature to verify a
    packet can be expensive especially for large packets) to be useful in
    some cases.

    Signed-off-by: Steve French
    Reviewed-by: Ronnie Sahlberg

    Steve French
     
  • which can be used from contexts where we have a TCP_Server_Info *server.
    This new macro will prepend the debugging string with "Server: "
    which will help when debugging issues on hosts with many cifs connections
    to several different servers.

    Convert a bunch of cifs_dbg(VFS) calls to cifs_server_dbg(VFS)

    Signed-off-by: Ronnie Sahlberg
    Signed-off-by: Steve French

    Ronnie Sahlberg
     

08 Jul, 2019

1 commit


06 Mar, 2019

2 commits


05 Mar, 2019

1 commit

  • When we hit failures during constructing MIDs or sending PDUs
    through the network, we end up not using message IDs assigned
    to the packet. The next SMB packet will skip those message IDs
    and continue with the next one. This behavior may lead to a server
    not granting us credits until we use the skipped IDs. Fix this by
    reverting the current ID to the original value if any errors occur
    before we push the packet through the network stack.

    This patch fixes the generic/310 test from the xfs-tests.

    Cc: # 4.19.x
    Signed-off-by: Pavel Shilovsky
    Signed-off-by: Steve French

    Pavel Shilovsky
     

08 Aug, 2018

2 commits

  • server->secmech.sdeschmacsha256 is not properly initialized before
    smb2_shash_allocate(), set shash after that call.

    also fix typo in error message

    Fixes: 8de8c4608fe9 ("cifs: Fix validation of signed data in smb2")

    Signed-off-by: Aurelien Aptel
    Reviewed-by: Paulo Alcantara
    Reported-by: Xiaoli Feng
    Signed-off-by: Steve French
    CC: Stable

    Aurelien Aptel
     
  • We really, really want to be encouraging use of secure dialects,
    and SMB3.1.1 offers useful security features, and will soon
    be the recommended dialect for many use cases. Simplify the code
    by removing the CONFIG_CIFS_SMB311 ifdef so users don't disable
    it in the build, and create compatibility and/or security issues
    with modern servers - many of which have been supporting this
    dialect for multiple years.

    Also clarify some of the Kconfig text for cifs.ko about
    SMB3.1.1 and current supported features in the module.

    Signed-off-by: Steve French
    Acked-by: Aurelien Aptel
    Reviewed-by: Ronnie Sahlberg

    Steve French
     

06 Jul, 2018

3 commits

  • Fixes: c713c8770fa5 ("cifs: push rfc1002 generation down the stack")

    We failed to validate signed data returned by the server because
    __cifs_calc_signature() now expects to sign the actual data in iov but
    we were also passing down the rfc1002 length.

    Fix smb3_calc_signature() to calculate signature of rfc1002 length prior
    to passing only the actual data iov[1-N] to __cifs_calc_signature(). In
    addition, there are a few cases where no rfc1002 length is passed so we
    make sure there's one (iov_len == 4).

    Signed-off-by: Paulo Alcantara
    Reviewed-by: Ronnie Sahlberg
    Signed-off-by: Steve French

    Paulo Alcantara
     
  • Fixes: c713c8770fa5 ("cifs: push rfc1002 generation down the stack")

    We failed to validate signed data returned by the server because
    __cifs_calc_signature() now expects to sign the actual data in iov but
    we were also passing down the rfc1002 length.

    Fix smb3_calc_signature() to calculate signature of rfc1002 length prior
    to passing only the actual data iov[1-N] to __cifs_calc_signature(). In
    addition, there are a few cases where no rfc1002 length is passed so we
    make sure there's one (iov_len == 4).

    Signed-off-by: Paulo Alcantara
    Reviewed-by: Ronnie Sahlberg
    Signed-off-by: Steve French

    Paulo Alcantara
     
  • 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: Lars Persson
    Acked-by: Paulo Alcantara
    Reviewed-by: Ronnie Sahlberg
    Reviewed-by: Pavel Shilovsky
    Signed-off-by: Steve French

    Lars Persson
     

15 Jun, 2018

1 commit


05 Jun, 2018

1 commit

  • It seems Ronnie's preamble removal broke signing.

    the signing functions are called when:

    A) we send a request (to sign it)
    B) when we recv a response (to check the signature).

    On code path A, the smb2 header is in iov[1] but on code path B, the
    smb2 header is in iov[0] (and there's only one vector).

    So we have different iov indexes for the smb2 header but the signing
    function always use index 1. Fix this by checking the nb of io vectors
    in the signing function as a hint.

    Signed-off-by: Aurelien Aptel
    Reviewed-by: Ronnie Sahlberg
    Signed-off-by: Steve French

    Aurelien Aptel
     

01 Jun, 2018

1 commit

  • Separate out all the 4 byte rfc1002 headers so that they are no longer
    part of the SMB2 header structures to prepare for future work to add
    compounding support.

    Update the smb3 transform header processing that we no longer have
    a rfc1002 header at the start of this structure.

    Update smb2_readv_callback to accommodate that the first iovector in the
    response is no the smb2 header and no longer a rfc1002 header.

    Signed-off-by: Ronnie Sahlberg
    Signed-off-by: Steve French

    Ronnie Sahlberg
     

13 Apr, 2018

1 commit


02 Apr, 2018

2 commits

  • * prepare for SMB3.11 pre-auth integrity
    * enable sha512 when SMB311 is enabled in Kconfig
    * add sha512 as a soft dependency

    Signed-off-by: Aurelien Aptel
    Signed-off-by: Steve French
    CC: Stable
    Reviewed-by: Ronnie Sahlberg

    Aurelien Aptel
     
  • shash and sdesc and always allocated and freed together.
    * abstract this in new functions cifs_alloc_hash() and cifs_free_hash().
    * make smb2/3 crypto allocation independent from each other.

    Signed-off-by: Aurelien Aptel
    Signed-off-by: Steve French
    Reviewed-by: Ronnie Sahlberg
    CC: Stable

    Aurelien Aptel
     

19 Oct, 2017

1 commit


06 Jul, 2017

1 commit


28 Apr, 2017

1 commit


07 Apr, 2017

1 commit

  • 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: Sachin Prabhu
    Reviewed-by: Pavel Shilovsky
    Cc: Stable

    Sachin Prabhu
     

02 Feb, 2017

4 commits


29 Mar, 2016

1 commit


15 Jan, 2016

1 commit


15 Dec, 2014

1 commit

  • We have encountered failures when When testing smb2 mounts on ppc64
    machines when using both Samba as well as Windows 2012.

    On poking around, the problem was determined to be caused by the
    high endian MessageID passed in the header for smb2. On checking the
    corresponding MID for smb1 is converted to LE before being sent on the
    wire.

    We have tested this patch successfully on a ppc64 machine.

    Signed-off-by: Sachin Prabhu

    Sachin Prabhu
     

02 Aug, 2014

1 commit

  • If we negotiate SMB 2.1 and higher version of the protocol and
    a server supports large write buffer size, we need to consume 1
    credit per 65536 bytes. So, we need to know how many credits
    we have and obtain the required number of them before constructing
    a writedata structure in writepages and iovec write.

    Reviewed-by: Shirish Pargaonkar
    Signed-off-by: Pavel Shilovsky
    Signed-off-by: Steve French

    Pavel Shilovsky
     

03 Nov, 2013

1 commit

  • 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: Shirish Pargaonkar
    Reviewed-by: Jeff Layton
    Signed-off-by: Steve French

    Shirish Pargaonkar