Skip to content
Snippets Groups Projects
  1. Sep 29, 2022
  2. May 07, 2022
    • Ronnie Sahlberg's avatar
      cifs: fix double free race when mount fails in cifs_get_root() · 7959a470
      Ronnie Sahlberg authored
      stable inclusion
      from linux-4.19.233
      commit 2fe0e281f7ad0a62259649764228227dd6b2561d
      category: bugfix
      bugzilla: https://gitee.com/openeuler/kernel/issues/I5646A
      
      
      CVE: NA
      
      --------------------------------
      
      [ Upstream commit 3d6cc9898efdfb062efb74dc18cfc700e082f5d5 ]
      
      When cifs_get_root() fails during cifs_smb3_do_mount() we call
      deactivate_locked_super() which eventually will call delayed_free() which
      will free the context.
      In this situation we should not proceed to enter the out: section in
      cifs_smb3_do_mount() and free the same resources a second time.
      
      [Thu Feb 10 12:59:06 2022] BUG: KASAN: use-after-free in rcu_cblist_dequeue+0x32/0x60
      [Thu Feb 10 12:59:06 2022] Read of size 8 at addr ffff888364f4d110 by task swapper/1/0
      
      [Thu Feb 10 12:59:06 2022] CPU: 1 PID: 0 Comm: swapper/1 Tainted: G           OE     5.17.0-rc3+ #4
      [Thu Feb 10 12:59:06 2022] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.0 12/17/2019
      [Thu Feb 10 12:59:06 2022] Call Trace:
      [Thu Feb 10 12:59:06 2022]  <IRQ>
      [Thu Feb 10 12:59:06 2022]  dump_stack_lvl+0x5d/0x78
      [Thu Feb 10 12:59:06 2022]  print_address_description.constprop.0+0x24/0x150
      [Thu Feb 10 12:59:06 2022]  ? rcu_cblist_dequeue+0x32/0x60
      [Thu Feb 10 12:59:06 2022]  kasan_report.cold+0x7d/0x117
      [Thu Feb 10 12:59:06 2022]  ? rcu_cblist_dequeue+0x32/0x60
      [Thu Feb 10 12:59:06 2022]  __asan_load8+0x86/0xa0
      [Thu Feb 10 12:59:06 2022]  rcu_cblist_dequeue+0x32/0x60
      [Thu Feb 10 12:59:06 2022]  rcu_core+0x547/0xca0
      [Thu Feb 10 12:59:06 2022]  ? call_rcu+0x3c0/0x3c0
      [Thu Feb 10 12:59:06 2022]  ? __this_cpu_preempt_check+0x13/0x20
      [Thu Feb 10 12:59:06 2022]  ? lock_is_held_type+0xea/0x140
      [Thu Feb 10 12:59:06 2022]  rcu_core_si+0xe/0x10
      [Thu Feb 10 12:59:06 2022]  __do_softirq+0x1d4/0x67b
      [Thu Feb 10 12:59:06 2022]  __irq_exit_rcu+0x100/0x150
      [Thu Feb 10 12:59:06 2022]  irq_exit_rcu+0xe/0x30
      [Thu Feb 10 12:59:06 2022]  sysvec_hyperv_stimer0+0x9d/0xc0
      ...
      [Thu Feb 10 12:59:07 2022] Freed by task 58179:
      [Thu Feb 10 12:59:07 2022]  kasan_save_stack+0x26/0x50
      [Thu Feb 10 12:59:07 2022]  kasan_set_track+0x25/0x30
      [Thu Feb 10 12:59:07 2022]  kasan_set_free_info+0x24/0x40
      [Thu Feb 10 12:59:07 2022]  ____kasan_slab_free+0x137/0x170
      [Thu Feb 10 12:59:07 2022]  __kasan_slab_free+0x12/0x20
      [Thu Feb 10 12:59:07 2022]  slab_free_freelist_hook+0xb3/0x1d0
      [Thu Feb 10 12:59:07 2022]  kfree+0xcd/0x520
      [Thu Feb 10 12:59:07 2022]  cifs_smb3_do_mount+0x149/0xbe0 [cifs]
      [Thu Feb 10 12:59:07 2022]  smb3_get_tree+0x1a0/0x2e0 [cifs]
      [Thu Feb 10 12:59:07 2022]  vfs_get_tree+0x52/0x140
      [Thu Feb 10 12:59:07 2022]  path_mount+0x635/0x10c0
      [Thu Feb 10 12:59:07 2022]  __x64_sys_mount+0x1bf/0x210
      [Thu Feb 10 12:59:07 2022]  do_syscall_64+0x5c/0xc0
      [Thu Feb 10 12:59:07 2022]  entry_SYSCALL_64_after_hwframe+0x44/0xae
      
      [Thu Feb 10 12:59:07 2022] Last potentially related work creation:
      [Thu Feb 10 12:59:07 2022]  kasan_save_stack+0x26/0x50
      [Thu Feb 10 12:59:07 2022]  __kasan_record_aux_stack+0xb6/0xc0
      [Thu Feb 10 12:59:07 2022]  kasan_record_aux_stack_noalloc+0xb/0x10
      [Thu Feb 10 12:59:07 2022]  call_rcu+0x76/0x3c0
      [Thu Feb 10 12:59:07 2022]  cifs_umount+0xce/0xe0 [cifs]
      [Thu Feb 10 12:59:07 2022]  cifs_kill_sb+0xc8/0xe0 [cifs]
      [Thu Feb 10 12:59:07 2022]  deactivate_locked_super+0x5d/0xd0
      [Thu Feb 10 12:59:07 2022]  cifs_smb3_do_mount+0xab9/0xbe0 [cifs]
      [Thu Feb 10 12:59:07 2022]  smb3_get_tree+0x1a0/0x2e0 [cifs]
      [Thu Feb 10 12:59:07 2022]  vfs_get_tree+0x52/0x140
      [Thu Feb 10 12:59:07 2022]  path_mount+0x635/0x10c0
      [Thu Feb 10 12:59:07 2022]  __x64_sys_mount+0x1bf/0x210
      [Thu Feb 10 12:59:07 2022]  do_syscall_64+0x5c/0xc0
      [Thu Feb 10 12:59:07 2022]  entry_SYSCALL_64_after_hwframe+0x44/0xae
      
      Reported-by: default avatarShyam Prasad N <sprasad@microsoft.com>
      Reviewed-by: default avatarShyam Prasad N <sprasad@microsoft.com>
      Signed-off-by: default avatarRonnie Sahlberg <lsahlber@redhat.com>
      Signed-off-by: default avatarSteve French <stfrench@microsoft.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      Signed-off-by: default avatarYongqiang Liu <liuyongqiang13@huawei.com>
      7959a470
  3. Apr 14, 2021
  4. Dec 27, 2019
  5. Nov 27, 2018
  6. Aug 11, 2018
  7. Aug 08, 2018
  8. Jun 07, 2018
    • Steve French's avatar
      smb3: do not allow insecure cifs mounts when using smb3 · c7c137b9
      Steve French authored
      
      if mounting as smb3 do not allow cifs (vers=1.0) or insecure vers=2.0
      mounts.
      
      For example:
      root@smf-Thinkpad-P51:~/cifs-2.6# mount -t smb3 //127.0.0.1/scratch /mnt -o username=testuser,password=Testpass1
      root@smf-Thinkpad-P51:~/cifs-2.6# umount /mnt
      root@smf-Thinkpad-P51:~/cifs-2.6# mount -t smb3 //127.0.0.1/scratch /mnt -o username=testuser,password=Testpass1,vers=1.0
      mount: /mnt: wrong fs type, bad option, bad superblock on //127.0.0.1/scratch ...
      root@smf-Thinkpad-P51:~/cifs-2.6# dmesg | grep smb3
      [ 4302.200122] CIFS VFS: vers=1.0 (cifs) not permitted when mounting with smb3
      root@smf-Thinkpad-P51:~/cifs-2.6# mount -t smb3 //127.0.0.1/scratch /mnt -o username=testuser,password=Testpass1,vers=3.11
      
      Signed-off-by: default avatarSteve French <stfrench@microsoft.com>
      Acked-by: default avatarPavel Shilovsky <pshilov@microsoft.com>
      Reviewed-by: default avatarAurelien Aptel <aaptel@suse.com>
      Reviewed-by: default avatarSachin Prabhu <sprabhu@redhat.com>
      c7c137b9
  9. May 31, 2018
  10. May 28, 2018
    • Steve French's avatar
      smb3: fix redundant opens on root · 3d4ef9a1
      Steve French authored
      
      In SMB2/SMB3 unlike in cifs we unnecessarily open the root of the share
      over and over again in various places during mount and path revalidation
      and also in statfs.  This patch cuts redundant traffic (opens and closes)
      by simply keeping the directory handle for the root around (and reopening
      it as needed on reconnect), so query calls don't require three round
      trips to copmlete - just one, and eases load on network, client and
      server (on mount alone, cuts network traffic by more than a third).
      
      Also add a new cifs mount parm "nohandlecache" to allow users whose
      servers might have resource constraints (eg in case they have a server
      with so many users connecting to it that this extra handle per mount
      could possibly be a resource concern).
      
      Signed-off-by: default avatarSteve French <smfrench@gmail.com>
      Reviewed-by: default avatarRonnie Sahlberg <lsahlber@redhat.com>
      3d4ef9a1
  11. May 11, 2018
  12. Apr 02, 2018
  13. Jan 27, 2018
  14. Jan 25, 2018
  15. Jan 16, 2018
    • David Windsor's avatar
      cifs: Define usercopy region in cifs_request slab cache · de046449
      David Windsor authored
      
      CIFS request buffers, stored in the cifs_request slab cache, need to be
      copied to/from userspace.
      
      cache object allocation:
          fs/cifs/cifsfs.c:
              cifs_init_request_bufs():
                  ...
                  cifs_req_poolp = mempool_create_slab_pool(cifs_min_rcv,
                                                            cifs_req_cachep);
      
          fs/cifs/misc.c:
              cifs_buf_get():
                  ...
                  ret_buf = mempool_alloc(cifs_req_poolp, GFP_NOFS);
                  ...
                  return ret_buf;
      
      In support of usercopy hardening, this patch defines a region in the
      cifs_request slab cache in which userspace copy operations are allowed.
      
      This region is known as the slab cache's usercopy region. Slab caches
      can now check that each dynamically sized copy operation involving
      cache-managed memory falls entirely within the slab's usercopy region.
      
      This patch is verbatim from Brad Spengler/PaX Team's PAX_USERCOPY
      whitelisting code in the last public patch of grsecurity/PaX based on my
      understanding of the code. Changes or omissions from the original code are
      mine and don't reflect the original grsecurity/PaX code.
      
      Signed-off-by: default avatarDavid Windsor <dave@nullcore.net>
      [kees: adjust commit log, provide usage trace]
      Cc: Steve French <sfrench@samba.org>
      Cc: linux-cifs@vger.kernel.org
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      de046449
  16. Nov 28, 2017
    • Linus Torvalds's avatar
      Rename superblock flags (MS_xyz -> SB_xyz) · 1751e8a6
      Linus Torvalds authored
      
      This is a pure automated search-and-replace of the internal kernel
      superblock flags.
      
      The s_flags are now called SB_*, with the names and the values for the
      moment mirroring the MS_* flags that they're equivalent to.
      
      Note how the MS_xyz flags are the ones passed to the mount system call,
      while the SB_xyz flags are what we then use in sb->s_flags.
      
      The script to do this was:
      
          # places to look in; re security/*: it generally should *not* be
          # touched (that stuff parses mount(2) arguments directly), but
          # there are two places where we really deal with superblock flags.
          FILES="drivers/mtd drivers/staging/lustre fs ipc mm \
                  include/linux/fs.h include/uapi/linux/bfs_fs.h \
                  security/apparmor/apparmorfs.c security/apparmor/include/lib.h"
          # the list of MS_... constants
          SYMS="RDONLY NOSUID NODEV NOEXEC SYNCHRONOUS REMOUNT MANDLOCK \
                DIRSYNC NOATIME NODIRATIME BIND MOVE REC VERBOSE SILENT \
                POSIXACL UNBINDABLE PRIVATE SLAVE SHARED RELATIME KERNMOUNT \
                I_VERSION STRICTATIME LAZYTIME SUBMOUNT NOREMOTELOCK NOSEC BORN \
                ACTIVE NOUSER"
      
          SED_PROG=
          for i in $SYMS; do SED_PROG="$SED_PROG -e s/MS_$i/SB_$i/g"; done
      
          # we want files that contain at least one of MS_...,
          # with fs/namespace.c and fs/pnode.c excluded.
          L=$(for i in $SYMS; do git grep -w -l MS_$i $FILES; done| sort|uniq|grep -v '^fs/namespace.c'|grep -v '^fs/pnode.c')
      
          for f in $L; do sed -i $f $SED_PROG; done
      
      Requested-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      1751e8a6
  17. Sep 21, 2017
    • Shu Wang's avatar
      cifs: release cifs root_cred after exit_cifs · 94183331
      Shu Wang authored
      
      memory leak was found by kmemleak. exit_cifs_spnego
      should be called before cifs module removed, or
      cifs root_cred will not be released.
      
      kmemleak report:
      unreferenced object 0xffff880070a3ce40 (size 192):
        backtrace:
           kmemleak_alloc+0x4a/0xa0
           kmem_cache_alloc+0xc7/0x1d0
           prepare_kernel_cred+0x20/0x120
           init_cifs_spnego+0x2d/0x170 [cifs]
           0xffffffffc07801f3
           do_one_initcall+0x51/0x1b0
           do_init_module+0x60/0x1fd
           load_module+0x161e/0x1b60
           SYSC_finit_module+0xa9/0x100
           SyS_finit_module+0xe/0x10
      
      Signed-off-by: default avatarShu Wang <shuwang@redhat.com>
      Signed-off-by: default avatarSteve French <smfrench@gmail.com>
      Reviewed-by: default avatarRonnie Sahlberg <lsahlber@redhat.com>
      CC: Stable <stable@vger.kernel.org>
      94183331
  18. Sep 20, 2017
  19. Jul 09, 2017
  20. Jun 20, 2017
  21. May 03, 2017
    • Rabin Vincent's avatar
      CIFS: fix oplock break deadlocks · 3998e6b8
      Rabin Vincent authored
      
      When the final cifsFileInfo_put() is called from cifsiod and an oplock
      break work is queued, lockdep complains loudly:
      
       =============================================
       [ INFO: possible recursive locking detected ]
       4.11.0+ #21 Not tainted
       ---------------------------------------------
       kworker/0:2/78 is trying to acquire lock:
        ("cifsiod"){++++.+}, at: flush_work+0x215/0x350
      
       but task is already holding lock:
        ("cifsiod"){++++.+}, at: process_one_work+0x255/0x8e0
      
       other info that might help us debug this:
        Possible unsafe locking scenario:
      
              CPU0
              ----
         lock("cifsiod");
         lock("cifsiod");
      
        *** DEADLOCK ***
      
        May be due to missing lock nesting notation
      
       2 locks held by kworker/0:2/78:
        #0:  ("cifsiod"){++++.+}, at: process_one_work+0x255/0x8e0
        #1:  ((&wdata->work)){+.+...}, at: process_one_work+0x255/0x8e0
      
       stack backtrace:
       CPU: 0 PID: 78 Comm: kworker/0:2 Not tainted 4.11.0+ #21
       Workqueue: cifsiod cifs_writev_complete
       Call Trace:
        dump_stack+0x85/0xc2
        __lock_acquire+0x17dd/0x2260
        ? match_held_lock+0x20/0x2b0
        ? trace_hardirqs_off_caller+0x86/0x130
        ? mark_lock+0xa6/0x920
        lock_acquire+0xcc/0x260
        ? lock_acquire+0xcc/0x260
        ? flush_work+0x215/0x350
        flush_work+0x236/0x350
        ? flush_work+0x215/0x350
        ? destroy_worker+0x170/0x170
        __cancel_work_timer+0x17d/0x210
        ? ___preempt_schedule+0x16/0x18
        cancel_work_sync+0x10/0x20
        cifsFileInfo_put+0x338/0x7f0
        cifs_writedata_release+0x2a/0x40
        ? cifs_writedata_release+0x2a/0x40
        cifs_writev_complete+0x29d/0x850
        ? preempt_count_sub+0x18/0xd0
        process_one_work+0x304/0x8e0
        worker_thread+0x9b/0x6a0
        kthread+0x1b2/0x200
        ? process_one_work+0x8e0/0x8e0
        ? kthread_create_on_node+0x40/0x40
        ret_from_fork+0x31/0x40
      
      This is a real warning.  Since the oplock is queued on the same
      workqueue this can deadlock if there is only one worker thread active
      for the workqueue (which will be the case during memory pressure when
      the rescuer thread is handling it).
      
      Furthermore, there is at least one other kind of hang possible due to
      the oplock break handling if there is only worker.  (This can be
      reproduced without introducing memory pressure by having passing 1 for
      the max_active parameter of cifsiod.) cifs_oplock_break() can wait
      indefintely in the filemap_fdatawait() while the cifs_writev_complete()
      work is blocked:
      
       sysrq: SysRq : Show Blocked State
         task                        PC stack   pid father
       kworker/0:1     D    0    16      2 0x00000000
       Workqueue: cifsiod cifs_oplock_break
       Call Trace:
        __schedule+0x562/0xf40
        ? mark_held_locks+0x4a/0xb0
        schedule+0x57/0xe0
        io_schedule+0x21/0x50
        wait_on_page_bit+0x143/0x190
        ? add_to_page_cache_lru+0x150/0x150
        __filemap_fdatawait_range+0x134/0x190
        ? do_writepages+0x51/0x70
        filemap_fdatawait_range+0x14/0x30
        filemap_fdatawait+0x3b/0x40
        cifs_oplock_break+0x651/0x710
        ? preempt_count_sub+0x18/0xd0
        process_one_work+0x304/0x8e0
        worker_thread+0x9b/0x6a0
        kthread+0x1b2/0x200
        ? process_one_work+0x8e0/0x8e0
        ? kthread_create_on_node+0x40/0x40
        ret_from_fork+0x31/0x40
       dd              D    0   683    171 0x00000000
       Call Trace:
        __schedule+0x562/0xf40
        ? mark_held_locks+0x29/0xb0
        schedule+0x57/0xe0
        io_schedule+0x21/0x50
        wait_on_page_bit+0x143/0x190
        ? add_to_page_cache_lru+0x150/0x150
        __filemap_fdatawait_range+0x134/0x190
        ? do_writepages+0x51/0x70
        filemap_fdatawait_range+0x14/0x30
        filemap_fdatawait+0x3b/0x40
        filemap_write_and_wait+0x4e/0x70
        cifs_flush+0x6a/0xb0
        filp_close+0x52/0xa0
        __close_fd+0xdc/0x150
        SyS_close+0x33/0x60
        entry_SYSCALL_64_fastpath+0x1f/0xbe
      
       Showing all locks held in the system:
       2 locks held by kworker/0:1/16:
        #0:  ("cifsiod"){.+.+.+}, at: process_one_work+0x255/0x8e0
        #1:  ((&cfile->oplock_break)){+.+.+.}, at: process_one_work+0x255/0x8e0
      
       Showing busy workqueues and worker pools:
       workqueue cifsiod: flags=0xc
         pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=1/1
           in-flight: 16:cifs_oplock_break
           delayed: cifs_writev_complete, cifs_echo_request
       pool 0: cpus=0 node=0 flags=0x0 nice=0 hung=0s workers=3 idle: 750 3
      
      Fix these problems by creating a a new workqueue (with a rescuer) for
      the oplock break work.
      
      Signed-off-by: default avatarRabin Vincent <rabinv@axis.com>
      Signed-off-by: default avatarSteve French <smfrench@gmail.com>
      CC: Stable <stable@vger.kernel.org>
      3998e6b8
  22. Apr 21, 2017
  23. Apr 07, 2017
    • Sachin Prabhu's avatar
      Introduce cifs_copy_file_range() · 620d8745
      Sachin Prabhu authored
      
      The earlier changes to copy range for cifs unintentionally disabled the more
      common form of server side copy.
      
      The patch introduces the file_operations helper cifs_copy_file_range()
      which is used by the syscall copy_file_range. The new file operations
      helper allows us to perform server side copies for SMB2.0 and 2.1
      servers as well as SMB 3.0+ servers which do not support the ioctl
      FSCTL_DUPLICATE_EXTENTS_TO_FILE.
      
      The new helper uses the ioctl FSCTL_SRV_COPYCHUNK_WRITE to perform
      server side copies. The helper is called by vfs_copy_file_range() only
      once an attempt to clone the file using the ioctl
      FSCTL_DUPLICATE_EXTENTS_TO_FILE has failed.
      
      Signed-off-by: default avatarSachin Prabhu <sprabhu@redhat.com>
      Reviewed-by: default avatarPavel Shilovsky <pshilov@microsoft.com>
      CC: Stable  <stable@vger.kernel.org>
      Signed-off-by: default avatarSteve French <smfrench@gmail.com>
      620d8745
  24. Mar 29, 2017
  25. Feb 02, 2017
  26. Dec 15, 2016
    • Sachin Prabhu's avatar
      cifs_get_root shouldn't use path with tree name · 374402a2
      Sachin Prabhu authored
      
      When a server returns the optional flag SMB_SHARE_IS_IN_DFS in response
      to a tree connect, cifs_build_path_to_root() will return a pathname
      which includes the hostname. This causes problems with cifs_get_root()
      which separates each component and does a lookup for each component of
      the path which in this case will incorrectly include looking up the
      hostname component as a path component.
      
      We encountered a problem with dfs shares hosted by a Netapp. When
      connecting to nodes pointed to by the DFS share. The tree connect for
      these nodes return SMB_SHARE_IS_IN_DFS resulting failures in lookup
      in cifs_get_root().
      
      RH bz: 1373153
      The patch was tested against a Netapp simulator and by a user using an
      actual Netapp server.
      
      Signed-off-by: default avatarSachin Prabhu <sprabhu@redhat.com>
      Reported-by: default avatarPierguido Lambri <plambri@redhat.com>
      Reviewed-by: default avatarJeff Layton <jlayton@redhat.com>
      Signed-off-by: default avatarSteve French <smfrench@gmail.com>
      374402a2
  27. Dec 09, 2016
  28. Oct 15, 2016
  29. Oct 14, 2016
  30. Oct 13, 2016
  31. Oct 08, 2016
  32. Sep 27, 2016