GHSA-FPPR-V7H4-2G4V
Vulnerability from github – Published: 2024-06-19 15:30 – Updated: 2024-10-31 00:30In 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\u0027t 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-\u003edescs 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\u0027s\n applicable only there.\n - Function mlx5_ib_dereg_mr() will now call mlx5_free_priv_descs() only\n in case there isn\u0027t udata, which indicates that this isn\u0027t 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"
}
]
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.