In the Linux kernel, the following vulnerability has been resolved:
RDMA/mlx5: Fix releasing unallocated memory in dereg MR flow
For the case of IBMRTYPEDM the mr does doesn't have a umem, even though it is a user MR. This causes function mlx5freeprivdescs() 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: mlx5core 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 checkunmap+0x54f/0x8b0 RIP: 0010:checkunmap+0x54f/0x8b0 Call Trace: debugdmaunmappage+0x57/0x60 mlx5freeprivdescs+0x57/0x70 [mlx5ib] mlx5ibderegmr+0x1fb/0x3d0 [mlx5ib] ibderegmruser+0x60/0x140 [ibcore] uverbsdestroyuobject+0x59/0x210 [ibuverbs] uobjdestroy+0x3f/0x80 [ibuverbs] ibuverbscmdverbs+0x435/0xd10 [ibuverbs] ? uverbsfinalizeobject+0x50/0x50 [ibuverbs] ? lockacquire+0xc4/0x2e0 ? lockacquired+0x12/0x380 ? lockacquire+0xc4/0x2e0 ? lockacquire+0xc4/0x2e0 ? ibuverbsioctl+0x7c/0x140 [ibuverbs] ? lockrelease+0x28a/0x400 ibuverbsioctl+0xc0/0x140 [ibuverbs] ? ibuverbsioctl+0x7c/0x140 [ibuverbs] _x64sysioctl+0x7f/0xb0 dosyscall_64+0x38/0x90
Fix it by reorganizing the dereg flow and mlx5ibmr structure: - Move the ibumem field into the user MRs structure in the union as it's applicable only there. - Function mlx5ibderegmr() will now call mlx5freepriv_descs() only in case there isn't udata, which indicates that this isn't a user MR.