ghsa-fppr-v7h4-2g4v
Vulnerability from github
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.
{ affected: [], aliases: [ "CVE-2021-47615", ], database_specific: { cwe_ids: [ "CWE-763", ], github_reviewed: false, github_reviewed_at: null, nvd_published_at: "2024-06-19T15:15:56Z", severity: "MODERATE", }, details: "In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/mlx5: Fix releasing unallocated memory in dereg MR flow\n\nFor the case of IB_MR_TYPE_DM the mr does doesn't have a umem, even though\nit is a user MR. This causes function mlx5_free_priv_descs() to think that\nit is a kernel MR, leading to wrongly accessing mr->descs that will get\nwrong values in the union which leads to attempt to release resources that\nwere not allocated in the first place.\n\nFor example:\n 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]\n WARNING: CPU: 8 PID: 1021 at kernel/dma/debug.c:961 check_unmap+0x54f/0x8b0\n RIP: 0010:check_unmap+0x54f/0x8b0\n Call Trace:\n debug_dma_unmap_page+0x57/0x60\n mlx5_free_priv_descs+0x57/0x70 [mlx5_ib]\n mlx5_ib_dereg_mr+0x1fb/0x3d0 [mlx5_ib]\n ib_dereg_mr_user+0x60/0x140 [ib_core]\n uverbs_destroy_uobject+0x59/0x210 [ib_uverbs]\n uobj_destroy+0x3f/0x80 [ib_uverbs]\n ib_uverbs_cmd_verbs+0x435/0xd10 [ib_uverbs]\n ? uverbs_finalize_object+0x50/0x50 [ib_uverbs]\n ? lock_acquire+0xc4/0x2e0\n ? lock_acquired+0x12/0x380\n ? lock_acquire+0xc4/0x2e0\n ? lock_acquire+0xc4/0x2e0\n ? ib_uverbs_ioctl+0x7c/0x140 [ib_uverbs]\n ? lock_release+0x28a/0x400\n ib_uverbs_ioctl+0xc0/0x140 [ib_uverbs]\n ? ib_uverbs_ioctl+0x7c/0x140 [ib_uverbs]\n __x64_sys_ioctl+0x7f/0xb0\n do_syscall_64+0x38/0x90\n\nFix it by reorganizing the dereg flow and mlx5_ib_mr structure:\n - Move the ib_umem field into the user MRs structure in the union as it's\n applicable only there.\n - Function mlx5_ib_dereg_mr() will now call mlx5_free_priv_descs() only\n in case there isn't udata, which indicates that this isn't a user MR.", id: "GHSA-fppr-v7h4-2g4v", modified: "2024-10-31T00:30:36Z", published: "2024-06-19T15:30:55Z", references: [ { type: "ADVISORY", url: "https://nvd.nist.gov/vuln/detail/CVE-2021-47615", }, { type: "WEB", url: "https://git.kernel.org/stable/c/c44979ace49b4aede3cc7cb5542316e53a4005c9", }, { type: "WEB", url: "https://git.kernel.org/stable/c/e3bc4d4b50cae7db08e50dbe43f771c906e97701", }, { type: "WEB", url: "https://git.kernel.org/stable/c/f0ae4afe3d35e67db042c58a52909e06262b740f", }, ], schema_version: "1.4.0", severity: [ { score: "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H", type: "CVSS_V3", }, ], }
Log in or create an account to share your comment.
This schema specifies the format of a comment related to a security advisory.
Sightings
Author | Source | Type | Date |
---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
- Confirmed: The vulnerability is confirmed from an analyst perspective.
- Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
- Patched: This vulnerability was successfully patched by the user reporting the sighting.
- Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
- Not confirmed: The user expresses doubt about the veracity of the vulnerability.
- Not patched: This vulnerability was not successfully patched by the user reporting the sighting.