Created attachment 234462 [details] a possible patch If uverbs_user_mmap_disassociate() is called while the mmap is concurrently doing exit_mmap then the ordering of the rdma_user_mmap_entry_put() is not reliable. The put must be done before uvers_user_mmap_disassociate() returns, otherwise there can be a use after free on the ucontext, and a left over entry in the xarray. If the put is not done here then it is done during rdma_umap_close() later. Add the missing put to the error exit path.
Need to check this a bit first.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=9fc6a635220fdd8a0a29de0a985a4a0c3a6890fd commit 9fc6a635220fdd8a0a29de0a985a4a0c3a6890fd Author: Hans Petter Selasky <hselasky@FreeBSD.org> AuthorDate: 2022-06-21 09:23:55 +0000 Commit: Hans Petter Selasky <hselasky@FreeBSD.org> CommitDate: 2022-06-21 09:33:27 +0000 ibcore: Fix a race with disassociate and exit_mmap() If uverbs_user_mmap_disassociate() is called while the mmap is concurrently doing exit_mmap then the ordering of the rdma_user_mmap_entry_put() is not reliable. The put must be done before uvers_user_mmap_disassociate() returns, otherwise there can be a use after free on the ucontext, and a left over entry in the xarray. If the put is not done here then it is done during rdma_umap_close() later. Add the missing put to the error exit path. Linux commit: 39c011a538272589b9eb02ff1228af528522a22c PR: 264473 MFC after: 3 days Sponsored by: NVIDIA Networking sys/ofed/drivers/infiniband/core/ib_uverbs_main.c | 4 ++++ 1 file changed, 4 insertions(+)
Thank you!