[Bug 295684] mlx4ib: leak SRQ resources on mlx4_ib_create_srq() copyout failure

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=295684

            Bug ID: 295684
           Summary: mlx4ib: leak SRQ resources on mlx4_ib_create_srq()
                    copyout failure
           Product: Base System
           Version: CURRENT
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Some People
          Priority: ---
         Component: kern
          Assignee: bugs@FreeBSD.org
          Reporter: lihaoxiang@isrc.iscas.ac.cn

Created attachment 271311
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=271311&action=edit
possible patch

In mlx4_ib_create_srq(), if ib_copy_to_udata() fails after mlx4_srq_alloc()
succeeds, the current error path jumps directly to err_wrid. This leaves the
mlx4 core SRQ resources allocated and leaves the SRQ in the radix tree.

An ib_copy_to_udata() failure is easy to trigger from userspace through uverbs.
A malformed or fuzzed CREATE_SRQ/CREATE_XSRQ request can provide an invalid
output buffer causing ib_copy_to_udata() to return -EFAULT.

The uverbs path calls __uverbs_create_xsrq() -> pd->device->create_srq(), and
mlx4 registers that callback as mlx4_ib_create_srq().  When create_srq returns
an error, uverbs frees the driver SRQ object.  Since the mlx4 SRQ radix tree
entry was not removed, later mlx4 SRQ lookup/event paths may observe a stale
pointer.

I used a minimal ownership harness to model the exact error path because I do
not have mlx4/ConnectX hardware for direct testing or passthrough.

The result shows that the cleanup is necessary.

-- 
You are receiving this mail because:
You are the assignee for the bug.