Date: Fri, 29 May 2026 09:26:52 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 295684] mlx4ib: leak SRQ resources on mlx4_ib_create_srq() copyout failure Message-ID: <bug-295684-227@https.bugs.freebsd.org/bugzilla/>
index | next in thread | raw e-mail
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.home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-295684-227>