ghsa-fppr-v7h4-2g4v
Vulnerability from github
Published
2024-06-19 15:30
Modified
2024-10-31 00:30
Details

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.

Show details on source website


{
   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.

Security Advisory comment format.

This schema specifies the format of a comment related to a security advisory.

UUIDv4 of the comment
UUIDv4 of the Vulnerability-Lookup instance
When the comment was created originally
When the comment was last updated
Title of the comment
Description of the comment
The identifier of the vulnerability (CVE ID, GHSA-ID, PYSEC ID, etc.).



Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

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.