An error occurred fetching the project authors.
  1. 24 Apr, 2020 1 commit
  2. 22 Apr, 2020 2 commits
    • Leon Romanovsky's avatar
      RDMA/core: Fix overwriting of uobj in case of error · 83a26702
      Leon Romanovsky authored
      In case of failure to get file, the uobj is overwritten and causes to
      supply bad pointer as an input to uverbs_uobject_put().
      
        BUG: KASAN: null-ptr-deref in atomic_fetch_sub include/asm-generic/atomic-instrumented.h:199 [inline]
        BUG: KASAN: null-ptr-deref in refcount_sub_and_test include/linux/refcount.h:253 [inline]
        BUG: KASAN: null-ptr-deref in refcount_dec_and_test include/linux/refcount.h:281 [inline]
        BUG: KASAN: null-ptr-deref in kref_put include/linux/kref.h:64 [inline]
        BUG: KASAN: null-ptr-deref in uverbs_uobject_put+0x22/0x90 drivers/infiniband/core/rdma_core.c:57
        Write of size 4 at addr 0000000000000030 by task syz-executor.4/1691
      
        CPU: 1 PID: 1691 Comm: syz-executor.4 Not tainted 5.6.0 #17
        Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014
        Call Trace:
         __dump_stack lib/dump_stack.c:77 [inline]
         dump_stack+0x94/0xce lib/dump_stack.c:118
         __kasan_report+0x10c/0x190 mm/kasan/report.c:515
         kasan_report+0x32/0x50 mm/kasan/common.c:625
         check_memory_region_inline mm/kasan/generic.c:187 [inline]
         check_memory_region+0x16d/0x1c0 mm/kasan/generic.c:193
         atomic_fetch_sub include/asm-generic/atomic-instrumented.h:199 [inline]
         refcount_sub_and_test include/linux/refcount.h:253 [inline]
         refcount_dec_and_test include/linux/refcount.h:281 [inline]
         kref_put include/linux/kref.h:64 [inline]
         uverbs_uobject_put+0x22/0x90 drivers/infiniband/core/rdma_core.c:57
         alloc_begin_fd_uobject+0x1d0/0x250 drivers/infiniband/core/rdma_core.c:486
         rdma_alloc_begin_uobject+0xa8/0xf0 drivers/infiniband/core/rdma_core.c:509
         __uobj_alloc include/rdma/uverbs_std_types.h:117 [inline]
         ib_uverbs_create_comp_channel+0x16d/0x230 drivers/infiniband/core/uverbs_cmd.c:982
         ib_uverbs_write+0xaa5/0xdf0 drivers/infiniband/core/uverbs_main.c:665
         __vfs_write+0x7c/0x100 fs/read_write.c:494
         vfs_write+0x168/0x4a0 fs/read_write.c:558
         ksys_write+0xc8/0x200 fs/read_write.c:611
         do_syscall_64+0x9c/0x390 arch/x86/entry/common.c:295
         entry_SYSCALL_64_after_hwframe+0x44/0xa9
        RIP: 0033:0x466479
        Code: f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48
        RSP: 002b:00007efe9f6a7c48 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
        RAX: ffffffffffffffda RBX: 000000000073bf00 RCX: 0000000000466479
        RDX: 0000000000000018 RSI: 0000000020000040 RDI: 0000000000000003
        RBP: 00007efe9f6a86bc R08: 0000000000000000 R09: 0000000000000000
        R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000005
        R13: 0000000000000bf2 R14: 00000000004cb80a R15: 00000000006fefc0
      
      Fixes: 849e1490 ("RDMA/core: Do not allow alloc_commit to fail")
      Link: https://lore.kernel.org/r/20200421082929.311931-3-leon@kernel.orgSigned-off-by: default avatarLeon Romanovsky <leonro@mellanox.com>
      Signed-off-by: default avatarJason Gunthorpe <jgg@mellanox.com>
      83a26702
    • Leon Romanovsky's avatar
      RDMA/core: Prevent mixed use of FDs between shared ufiles · 0fb00941
      Leon Romanovsky authored
      FDs can only be used on the ufile that created them, they cannot be mixed
      to other ufiles. We are lacking a check to prevent it.
      
        BUG: KASAN: null-ptr-deref in atomic64_sub_and_test include/asm-generic/atomic-instrumented.h:1547 [inline]
        BUG: KASAN: null-ptr-deref in atomic_long_sub_and_test include/asm-generic/atomic-long.h:460 [inline]
        BUG: KASAN: null-ptr-deref in fput_many+0x1a/0x140 fs/file_table.c:336
        Write of size 8 at addr 0000000000000038 by task syz-executor179/284
      
        CPU: 0 PID: 284 Comm: syz-executor179 Not tainted 5.5.0-rc5+ #1
        Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014
        Call Trace:
         __dump_stack lib/dump_stack.c:77 [inline]
         dump_stack+0x94/0xce lib/dump_stack.c:118
         __kasan_report+0x18f/0x1b7 mm/kasan/report.c:510
         kasan_report+0xe/0x20 mm/kasan/common.c:639
         check_memory_region_inline mm/kasan/generic.c:185 [inline]
         check_memory_region+0x15d/0x1b0 mm/kasan/generic.c:192
         atomic64_sub_and_test include/asm-generic/atomic-instrumented.h:1547 [inline]
         atomic_long_sub_and_test include/asm-generic/atomic-long.h:460 [inline]
         fput_many+0x1a/0x140 fs/file_table.c:336
         rdma_lookup_put_uobject+0x85/0x130 drivers/infiniband/core/rdma_core.c:692
         uobj_put_read include/rdma/uverbs_std_types.h:96 [inline]
         _ib_uverbs_lookup_comp_file drivers/infiniband/core/uverbs_cmd.c:198 [inline]
         create_cq+0x375/0xba0 drivers/infiniband/core/uverbs_cmd.c:1006
         ib_uverbs_create_cq+0x114/0x140 drivers/infiniband/core/uverbs_cmd.c:1089
         ib_uverbs_write+0xaa5/0xdf0 drivers/infiniband/core/uverbs_main.c:769
         __vfs_write+0x7c/0x100 fs/read_write.c:494
         vfs_write+0x168/0x4a0 fs/read_write.c:558
         ksys_write+0xc8/0x200 fs/read_write.c:611
         do_syscall_64+0x9c/0x390 arch/x86/entry/common.c:294
         entry_SYSCALL_64_after_hwframe+0x44/0xa9
        RIP: 0033:0x44ef99
        Code: 00 b8 00 01 00 00 eb e1 e8 74 1c 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 c4 ff ff ff f7 d8 64 89 01 48
        RSP: 002b:00007ffc0b74c028 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
        RAX: ffffffffffffffda RBX: 00007ffc0b74c030 RCX: 000000000044ef99
        RDX: 0000000000000040 RSI: 0000000020000040 RDI: 0000000000000005
        RBP: 00007ffc0b74c038 R08: 0000000000401830 R09: 0000000000401830
        R10: 00007ffc0b74c038 R11: 0000000000000246 R12: 0000000000000000
        R13: 0000000000000000 R14: 00000000006be018 R15: 0000000000000000
      
      Fixes: cf8966b3 ("IB/core: Add support for fd objects")
      Link: https://lore.kernel.org/r/20200421082929.311931-2-leon@kernel.orgSuggested-by: default avatarJason Gunthorpe <jgg@mellanox.com>
      Signed-off-by: default avatarLeon Romanovsky <leonro@mellanox.com>
      Signed-off-by: default avatarJason Gunthorpe <jgg@mellanox.com>
      0fb00941
  3. 16 Jan, 2020 1 commit
  4. 13 Jan, 2020 5 commits
  5. 06 Nov, 2019 1 commit
  6. 25 Apr, 2019 1 commit
  7. 08 Apr, 2019 1 commit
  8. 01 Apr, 2019 2 commits
  9. 22 Feb, 2019 1 commit
  10. 15 Feb, 2019 1 commit
  11. 29 Jan, 2019 1 commit
  12. 12 Dec, 2018 1 commit
  13. 04 Dec, 2018 1 commit
  14. 03 Dec, 2018 1 commit
  15. 26 Nov, 2018 2 commits
  16. 21 Sep, 2018 1 commit
  17. 20 Sep, 2018 2 commits
  18. 04 Sep, 2018 1 commit
  19. 13 Aug, 2018 1 commit
  20. 10 Aug, 2018 1 commit
    • Jason Gunthorpe's avatar
      IB/uverbs: Use uverbs_api to manage the object type inside the uobject · 6b0d08f4
      Jason Gunthorpe authored
      Currently the struct uverbs_obj_type stored in the ib_uobject is part of
      the .rodata segment of the module that defines the object. This is a
      problem if drivers define new uapi objects as we will be left with a
      dangling pointer after device disassociation.
      
      Switch the uverbs_obj_type for struct uverbs_api_object, which is
      allocated memory that is part of the uverbs_api and is guaranteed to
      always exist. Further this moves the 'type_class' into this memory which
      means access to the IDR/FD function pointers is also guaranteed. Drivers
      cannot define new types.
      
      This makes it safe to continue to use all uobjects, including driver
      defined ones, after disassociation.
      Signed-off-by: default avatarJason Gunthorpe <jgg@mellanox.com>
      6b0d08f4
  21. 01 Aug, 2018 8 commits
    • Jason Gunthorpe's avatar
      IB/uverbs: Allow all DESTROY commands to succeed after disassociate · 0f50d88a
      Jason Gunthorpe authored
      The disassociate function was broken by design because it failed all
      commands. This prevents userspace from calling destroy on a uobject after
      it has detected a device fatal error and thus reclaiming the resources in
      userspace is prevented.
      
      This fix is now straightforward, when anything destroys a uobject that is
      not the user the object remains on the IDR with a NULL context and object
      pointer. All lookup locking modes other than DESTROY will fail. When the
      user ultimately calls the destroy function it is simply dropped from the
      IDR while any related information is returned.
      Signed-off-by: default avatarJason Gunthorpe <jgg@mellanox.com>
      0f50d88a
    • Jason Gunthorpe's avatar
      IB/uverbs: Lower the test for ongoing disassociation · cc2e14e6
      Jason Gunthorpe authored
      Commands that are reading/writing to objects can test for an ongoing
      disassociation during their initial call to rdma_lookup_get_uobject.  This
      directly prevents all of these commands from conflicting with an ongoing
      disassociation.
      Signed-off-by: default avatarJason Gunthorpe <jgg@mellanox.com>
      cc2e14e6
    • Jason Gunthorpe's avatar
      IB/uverbs: Allow uobject allocation to work concurrently with disassociate · 1e857e65
      Jason Gunthorpe authored
      After all the recent structural changes this is now straightforward, hold
      the hw_destroy_rwsem across the entire uobject creation. We already take
      this semaphore on the success path, so holding it a bit longer is not
      going to change the performance.
      
      After this change none of the create callbacks require the
      disassociate_srcu lock to be correct.
      Signed-off-by: default avatarJason Gunthorpe <jgg@mellanox.com>
      1e857e65
    • Jason Gunthorpe's avatar
      IB/uverbs: Allow RDMA_REMOVE_DESTROY to work concurrently with disassociate · 7452a3c7
      Jason Gunthorpe authored
      After all the recent structural changes this is now straightfoward, hoist
      the hw_destroy_rwsem up out of rdma_destroy_explicit and wrap it around
      the uobject write lock as well as the destroy.
      
      This is necessary as obtaining a write lock concurrently with
      uverbs_destroy_ufile_hw() will cause malfunction.
      
      After this change none of the destroy callbacks require the
      disassociate_srcu lock to be correct.
      
      This requires introducing a new lookup mode, UVERBS_LOOKUP_DESTROY as the
      IOCTL interface needs to hold an unlocked kref until all command
      verification is completed.
      Signed-off-by: default avatarJason Gunthorpe <jgg@mellanox.com>
      7452a3c7
    • Jason Gunthorpe's avatar
      IB/uverbs: Convert 'bool exclusive' into an enum · 9867f5c6
      Jason Gunthorpe authored
      This is more readable, and future patches will need a 3rd lookup type.
      Signed-off-by: default avatarJason Gunthorpe <jgg@mellanox.com>
      9867f5c6
    • Jason Gunthorpe's avatar
      IB/uverbs: Consolidate uobject destruction · 87ad80ab
      Jason Gunthorpe authored
      There are several flows that can destroy a uobject and each one is
      minimized and sprinkled throughout the code base, making it difficult to
      understand and very hard to modify the destroy path.
      
      Consolidate all of these into uverbs_destroy_uobject() and call it in all
      cases where a uobject has to be destroyed.
      
      This makes one change to the lifecycle, during any abort (eg when
      alloc_commit is not called) we always call out to alloc_abort, even if
      remove_commit needs to be called to delete a HW object.
      
      This also renames RDMA_REMOVE_DURING_CLEANUP to RDMA_REMOVE_ABORT to
      clarify its actual usage and revises some of the comments to reflect what
      the life cycle is for the type implementation.
      Signed-off-by: default avatarJason Gunthorpe <jgg@mellanox.com>
      87ad80ab
    • Jason Gunthorpe's avatar
      IB/uverbs: Make the write path destroy methods use the same flow as ioctl · 32ed5c00
      Jason Gunthorpe authored
      The ridiculous dance with uobj_remove_commit() is not needed, the write
      path can follow the same flow as ioctl - lock and destroy the HW object
      then use the data left over in the uobject to form the response to
      userspace.
      
      Two helpers are introduced to make this flow straightforward for the
      caller.
      Signed-off-by: default avatarJason Gunthorpe <jgg@mellanox.com>
      32ed5c00
    • Jason Gunthorpe's avatar
      IB/uverbs: Remove rdma_explicit_destroy() from the ioctl methods · aa72c9a5
      Jason Gunthorpe authored
      The core code will destroy the HW object on behalf of the method, if the
      method provides an implementation it must simply copy data from the stub
      uobj into the response. Destroy methods cannot touch the HW object.
      Signed-off-by: default avatarJason Gunthorpe <jgg@mellanox.com>
      aa72c9a5
  22. 25 Jul, 2018 4 commits
    • Jason Gunthorpe's avatar
      IB/uverbs: Fix locking around struct ib_uverbs_file ucontext · 22fa27fb
      Jason Gunthorpe authored
      We have a parallel unlocked reader and writer with ib_uverbs_get_context()
      vs everything else, and nothing guarantees this works properly.
      
      Audit and fix all of the places that access ucontext to use one of the
      following locking schemes:
      - Call ib_uverbs_get_ucontext() under SRCU and check for failure
      - Access the ucontext through an struct ib_uobject context member
        while holding a READ or WRITE lock on the uobject.
        This value cannot be NULL and has no race.
      - Hold the ucontext_lock and check for ufile->ucontext !NULL
      
      This also re-implements ib_uverbs_get_ucontext() in a way that is safe
      against concurrent ib_uverbs_get_context() and disassociation.
      
      As a side effect, every access to ucontext in the commands is via
      ib_uverbs_get_context() with an error check, or via the uobject, so there
      is no longer any need for the core code to check ucontext on every command
      call. These checks are also removed.
      Signed-off-by: default avatarJason Gunthorpe <jgg@mellanox.com>
      22fa27fb
    • Jason Gunthorpe's avatar
      IB/uverbs: Move the FD uobj type struct file allocation to alloc_commit · aba94548
      Jason Gunthorpe authored
      Allocating the struct file during alloc_begin creates this strange
      asymmetry with IDR, where the FD has two krefs pointing at it during the
      pre-commit phase. In particular this makes the abort process for FD very
      strange and confusing.
      
      For instance abort currently calls the type's destroy_object twice, and
      the fops release once if abort is done. This is very counter intuitive. No
      fops should be called until alloc_commit succeeds, and destroy_object
      should only ever be called once.
      
      Moving the struct file allocation to the alloc_commit is now simple, as we
      already support failure of rdma_alloc_commit_uobject, with all the
      required rollback pieces.
      
      This creates an understandable symmetry with IDR and simplifies/fixes the
      abort handling for FD types.
      Signed-off-by: default avatarJason Gunthorpe <jgg@mellanox.com>
      aba94548
    • Jason Gunthorpe's avatar
      IB/uverbs: Always propagate errors from rdma_alloc_commit_uobject() · 2c96eb7d
      Jason Gunthorpe authored
      The ioctl framework already does this correctly, but the write path did
      not. This is trivially fixed by simply using a standard pattern to return
      uobj_alloc_commit() as the last statement in every function.
      Signed-off-by: default avatarJason Gunthorpe <jgg@mellanox.com>
      2c96eb7d
    • Jason Gunthorpe's avatar
      IB/uverbs: Rework the locking for cleaning up the ucontext · e951747a
      Jason Gunthorpe authored
      The locking here has always been a bit crazy and spread out, upon some
      careful analysis we can simplify things.
      
      Create a single function uverbs_destroy_ufile_hw() that internally handles
      all locking. This pulls together pieces of this process that were
      sprinkled all over the places into one place, and covers them with one
      lock.
      
      This eliminates several duplicate/confusing locks and makes the control
      flow in ib_uverbs_close() and ib_uverbs_free_hw_resources() extremely
      simple.
      
      Unfortunately we have to keep an extra mutex, ucontext_lock.  This lock is
      logically part of the rwsem and provides the 'down write, fail if write
      locked, wait if read locked' semantic we require.
      Signed-off-by: default avatarJason Gunthorpe <jgg@mellanox.com>
      e951747a