CVE-2021-47615

In the Linux kernel, the following vulnerability has been resolved:
RDMA/mlx5: Fix releasing unallocated memory in dereg MR flow For the case
of IB_MR_TYPE_DM the mr does doesn’t have a umem, even though it is a user
MR. This causes function mlx5_free_priv_descs() to think that it is a
kernel MR, leading to wrongly accessing mr->descs that will get wrong
values in the union which leads to attempt to release resources that were
not allocated in the first place. For example: DMA-API: mlx5_core
0000:08:00.1: device driver tries to free DMA memory it has not allocated
[device address=0x0000000000000000] [size=0 bytes] WARNING: CPU: 8 PID:
1021 at kernel/dma/debug.c:961 check_unmap+0x54f/0x8b0 RIP:
0010:check_unmap+0x54f/0x8b0 Call Trace: debug_dma_unmap_page+0x57/0x60
mlx5_free_priv_descs+0x57/0x70 [mlx5_ib] mlx5_ib_dereg_mr+0x1fb/0x3d0
[mlx5_ib] ib_dereg_mr_user+0x60/0x140 [ib_core]
uverbs_destroy_uobject+0x59/0x210 [ib_uverbs] uobj_destroy+0x3f/0x80
[ib_uverbs] ib_uverbs_cmd_verbs+0x435/0xd10 [ib_uverbs] ?
uverbs_finalize_object+0x50/0x50 [ib_uverbs] ? lock_acquire+0xc4/0x2e0 ?
lock_acquired+0x12/0x380 ? lock_acquire+0xc4/0x2e0 ?
lock_acquire+0xc4/0x2e0 ? ib_uverbs_ioctl+0x7c/0x140 [ib_uverbs] ?
lock_release+0x28a/0x400 ib_uverbs_ioctl+0xc0/0x140 [ib_uverbs] ?
ib_uverbs_ioctl+0x7c/0x140 [ib_uverbs] __x64_sys_ioctl+0x7f/0xb0
do_syscall_64+0x38/0x90 Fix it by reorganizing the dereg flow and
mlx5_ib_mr structure: - Move the ib_umem field into the user MRs structure
in the union as it’s applicable only there. - Function mlx5_ib_dereg_mr()
will now call mlx5_free_priv_descs() only in case there isn’t udata, which
indicates that this isn’t a user MR.