1. 05 5月, 2020 1 次提交
  2. 30 3月, 2020 19 次提交
  3. 27 1月, 2020 1 次提交
  4. 10 12月, 2019 2 次提交
  5. 30 10月, 2019 1 次提交
    • L
      ceph: fix use-after-free in __ceph_remove_cap() · ea60ed6f
      Luis Henriques 提交于
      KASAN reports a use-after-free when running xfstest generic/531, with the
      following trace:
      
      [  293.903362]  kasan_report+0xe/0x20
      [  293.903365]  rb_erase+0x1f/0x790
      [  293.903370]  __ceph_remove_cap+0x201/0x370
      [  293.903375]  __ceph_remove_caps+0x4b/0x70
      [  293.903380]  ceph_evict_inode+0x4e/0x360
      [  293.903386]  evict+0x169/0x290
      [  293.903390]  __dentry_kill+0x16f/0x250
      [  293.903394]  dput+0x1c6/0x440
      [  293.903398]  __fput+0x184/0x330
      [  293.903404]  task_work_run+0xb9/0xe0
      [  293.903410]  exit_to_usermode_loop+0xd3/0xe0
      [  293.903413]  do_syscall_64+0x1a0/0x1c0
      [  293.903417]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
      
      This happens because __ceph_remove_cap() may queue a cap release
      (__ceph_queue_cap_release) which can be scheduled before that cap is
      removed from the inode list with
      
      	rb_erase(&cap->ci_node, &ci->i_caps);
      
      And, when this finally happens, the use-after-free will occur.
      
      This can be fixed by removing the cap from the inode list before being
      removed from the session list, and thus eliminating the risk of an UAF.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NLuis Henriques <lhenriques@suse.com>
      Reviewed-by: NJeff Layton <jlayton@kernel.org>
      Signed-off-by: NIlya Dryomov <idryomov@gmail.com>
      ea60ed6f
  6. 16 9月, 2019 11 次提交
  7. 22 8月, 2019 1 次提交
    • L
      ceph: fix buffer free while holding i_ceph_lock in __ceph_build_xattrs_blob() · 12fe3dda
      Luis Henriques 提交于
      Calling ceph_buffer_put() in __ceph_build_xattrs_blob() may result in
      freeing the i_xattrs.blob buffer while holding the i_ceph_lock.  This can
      be fixed by having this function returning the old blob buffer and have
      the callers of this function freeing it when the lock is released.
      
      The following backtrace was triggered by fstests generic/117.
      
        BUG: sleeping function called from invalid context at mm/vmalloc.c:2283
        in_atomic(): 1, irqs_disabled(): 0, pid: 649, name: fsstress
        4 locks held by fsstress/649:
         #0: 00000000a7478e7e (&type->s_umount_key#19){++++}, at: iterate_supers+0x77/0xf0
         #1: 00000000f8de1423 (&(&ci->i_ceph_lock)->rlock){+.+.}, at: ceph_check_caps+0x7b/0xc60
         #2: 00000000562f2b27 (&s->s_mutex){+.+.}, at: ceph_check_caps+0x3bd/0xc60
         #3: 00000000f83ce16a (&mdsc->snap_rwsem){++++}, at: ceph_check_caps+0x3ed/0xc60
        CPU: 1 PID: 649 Comm: fsstress Not tainted 5.2.0+ #439
        Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58-prebuilt.qemu.org 04/01/2014
        Call Trace:
         dump_stack+0x67/0x90
         ___might_sleep.cold+0x9f/0xb1
         vfree+0x4b/0x60
         ceph_buffer_release+0x1b/0x60
         __ceph_build_xattrs_blob+0x12b/0x170
         __send_cap+0x302/0x540
         ? __lock_acquire+0x23c/0x1e40
         ? __mark_caps_flushing+0x15c/0x280
         ? _raw_spin_unlock+0x24/0x30
         ceph_check_caps+0x5f0/0xc60
         ceph_flush_dirty_caps+0x7c/0x150
         ? __ia32_sys_fdatasync+0x20/0x20
         ceph_sync_fs+0x5a/0x130
         iterate_supers+0x8f/0xf0
         ksys_sync+0x4f/0xb0
         __ia32_sys_sync+0xa/0x10
         do_syscall_64+0x50/0x1c0
         entry_SYSCALL_64_after_hwframe+0x49/0xbe
        RIP: 0033:0x7fc6409ab617
      Signed-off-by: NLuis Henriques <lhenriques@suse.com>
      Reviewed-by: NJeff Layton <jlayton@kernel.org>
      Signed-off-by: NIlya Dryomov <idryomov@gmail.com>
      12fe3dda
  8. 08 7月, 2019 4 次提交