1. 14 6月, 2018 1 次提交
  2. 13 6月, 2018 1 次提交
  3. 11 6月, 2018 1 次提交
  4. 09 6月, 2018 1 次提交
  5. 01 6月, 2018 4 次提交
  6. 31 5月, 2018 1 次提交
  7. 30 5月, 2018 1 次提交
  8. 25 5月, 2018 2 次提交
  9. 23 5月, 2018 1 次提交
  10. 19 5月, 2018 1 次提交
  11. 12 5月, 2018 1 次提交
  12. 07 5月, 2018 1 次提交
    • J
      nvme: fix use-after-free in nvme_free_ns_head · 12d9f070
      Jianchao Wang 提交于
      Currently only nvme_ctrl will take a reference counter of
      nvme_subsystem, nvme_ns_head also needs it. Otherwise
      nvme_free_ns_head will access the nvme_subsystem.ns_ida
      which has been freed by __nvme_release_subsystem after all the
      reference of nvme_subsystem have been released by nvme_free_ctrl.
      This could cause memory corruption.
      
       BUG: KASAN: use-after-free in radix_tree_next_chunk+0x9f/0x4b0
       Read of size 8 at addr ffff88036494d2e8 by task fio/1815
      
       CPU: 1 PID: 1815 Comm: fio Kdump: loaded Tainted: G        W         4.17.0-rc1+ #18
       Hardware name: LENOVO 10MLS0E339/3106, BIOS M1AKT22A 06/27/2017
       Call Trace:
        dump_stack+0x91/0xeb
        print_address_description+0x6b/0x290
        kasan_report+0x261/0x360
        radix_tree_next_chunk+0x9f/0x4b0
        ida_remove+0x8b/0x180
        ida_simple_remove+0x26/0x40
        nvme_free_ns_head+0x58/0xc0
        __blkdev_put+0x30a/0x3a0
        blkdev_close+0x44/0x50
        __fput+0x184/0x380
        task_work_run+0xaf/0xe0
        do_exit+0x501/0x1440
        do_group_exit+0x89/0x140
        __x64_sys_exit_group+0x28/0x30
        do_syscall_64+0x72/0x230
      Signed-off-by: NJianchao Wang <jianchao.w.wang@oracle.com>
      Reviewed-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NKeith Busch <keith.busch@intel.com>
      12d9f070
  13. 03 5月, 2018 3 次提交
  14. 12 4月, 2018 5 次提交
  15. 30 3月, 2018 2 次提交
  16. 26 3月, 2018 9 次提交
  17. 09 3月, 2018 1 次提交
  18. 07 3月, 2018 1 次提交
  19. 28 2月, 2018 1 次提交
    • B
      nvme-multipath: fix sysfs dangerously created links · 9bd82b1a
      Baegjae Sung 提交于
      If multipathing is enabled, each NVMe subsystem creates a head
      namespace (e.g., nvme0n1) and multiple private namespaces
      (e.g., nvme0c0n1 and nvme0c1n1) in sysfs. When creating links for
      private namespaces, links of head namespace are used, so the
      namespace creation order must be followed (e.g., nvme0n1 ->
      nvme0c1n1). If the order is not followed, links of sysfs will be
      incomplete or kernel panic will occur.
      
      The kernel panic was:
        kernel BUG at fs/sysfs/symlink.c:27!
        Call Trace:
          nvme_mpath_add_disk_links+0x5d/0x80 [nvme_core]
          nvme_validate_ns+0x5c2/0x850 [nvme_core]
          nvme_scan_work+0x1af/0x2d0 [nvme_core]
      
      Correct order
      Context A     Context B
      nvme0n1
      nvme0c0n1     nvme0c1n1
      
      Incorrect order
      Context A     Context B
                    nvme0c1n1
      nvme0n1
      nvme0c0n1
      
      The nvme_mpath_add_disk (for creating head namespace) is called
      just before the nvme_mpath_add_disk_links (for creating private
      namespaces). In nvme_mpath_add_disk, the first context acquires
      the lock of subsystem and creates a head namespace, and other
      contexts do nothing by checking GENHD_FL_UP of a head namespace
      after waiting to acquire the lock. We verified the code with or
      without multipathing using three vendors of dual-port NVMe SSDs.
      Signed-off-by: NBaegjae Sung <baegjae@gmail.com>
      Reviewed-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NKeith Busch <keith.busch@intel.com>
      9bd82b1a
  20. 14 2月, 2018 2 次提交