ghsa-hx83-mq38-jp75
Vulnerability from github
Published
2025-03-14 00:30
Modified
2025-03-14 00:30
Severity ?
4.7 (Medium) - CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
Details

In the Linux kernel, the following vulnerability has been resolved:

perf/core: Fix data race between perf_event_set_output() and perf_mmap_close()

Yang Jihing reported a race between perf_event_set_output() and perf_mmap_close():

CPU1                    CPU2

perf_mmap_close(e2)
  if (atomic_dec_and_test(&e2->rb->mmap_count)) // 1 - > 0
    detach_rest = true

                    ioctl(e1, IOC_SET_OUTPUT, e2)
                      perf_event_set_output(e1, e2)

  ...
  list_for_each_entry_rcu(e, &e2->rb->event_list, rb_entry)
    ring_buffer_attach(e, NULL);
    // e1 isn't yet added and
    // therefore not detached

                        ring_buffer_attach(e1, e2->rb)
                          list_add_rcu(&e1->rb_entry,
                               &e2->rb->event_list)

After this; e1 is attached to an unmapped rb and a subsequent perf_mmap() will loop forever more:

again:
    mutex_lock(&e->mmap_mutex);
    if (event->rb) {
        ...
        if (!atomic_inc_not_zero(&e->rb->mmap_count)) {
            ...
            mutex_unlock(&e->mmap_mutex);
            goto again;
        }
    }

The loop in perf_mmap_close() holds e2->mmap_mutex, while the attach in perf_event_set_output() holds e1->mmap_mutex. As such there is no serialization to avoid this race.

Change perf_event_set_output() to take both e1->mmap_mutex and e2->mmap_mutex to alleviate that problem. Additionally, have the loop in perf_mmap() detach the rb directly, this avoids having to wait for the concurrent perf_mmap_close() to get around to doing it to make progress.

Show details on source website

To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2022-49607"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-362"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-02-26T07:01:36Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nperf/core: Fix data race between perf_event_set_output() and perf_mmap_close()\n\nYang Jihing reported a race between perf_event_set_output() and\nperf_mmap_close():\n\n\tCPU1\t\t\t\t\tCPU2\n\n\tperf_mmap_close(e2)\n\t  if (atomic_dec_and_test(\u0026e2-\u003erb-\u003emmap_count)) // 1 - \u003e 0\n\t    detach_rest = true\n\n\t\t\t\t\t\tioctl(e1, IOC_SET_OUTPUT, e2)\n\t\t\t\t\t\t  perf_event_set_output(e1, e2)\n\n\t  ...\n\t  list_for_each_entry_rcu(e, \u0026e2-\u003erb-\u003eevent_list, rb_entry)\n\t    ring_buffer_attach(e, NULL);\n\t    // e1 isn\u0027t yet added and\n\t    // therefore not detached\n\n\t\t\t\t\t\t    ring_buffer_attach(e1, e2-\u003erb)\n\t\t\t\t\t\t      list_add_rcu(\u0026e1-\u003erb_entry,\n\t\t\t\t\t\t\t\t   \u0026e2-\u003erb-\u003eevent_list)\n\nAfter this; e1 is attached to an unmapped rb and a subsequent\nperf_mmap() will loop forever more:\n\n\tagain:\n\t\tmutex_lock(\u0026e-\u003emmap_mutex);\n\t\tif (event-\u003erb) {\n\t\t\t...\n\t\t\tif (!atomic_inc_not_zero(\u0026e-\u003erb-\u003emmap_count)) {\n\t\t\t\t...\n\t\t\t\tmutex_unlock(\u0026e-\u003emmap_mutex);\n\t\t\t\tgoto again;\n\t\t\t}\n\t\t}\n\nThe loop in perf_mmap_close() holds e2-\u003emmap_mutex, while the attach\nin perf_event_set_output() holds e1-\u003emmap_mutex. As such there is no\nserialization to avoid this race.\n\nChange perf_event_set_output() to take both e1-\u003emmap_mutex and\ne2-\u003emmap_mutex to alleviate that problem. Additionally, have the loop\nin perf_mmap() detach the rb directly, this avoids having to wait for\nthe concurrent perf_mmap_close() to get around to doing it to make\nprogress.",
  "id": "GHSA-hx83-mq38-jp75",
  "modified": "2025-03-14T00:30:52Z",
  "published": "2025-03-14T00:30:51Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49607"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/17f5417194136517ee9bbd6511249e5310e5617c"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/3bbd868099287ff9027db59029b502fcfa2202a0"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/43128b3eee337824158f34da6648163d2f2fb937"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/68e3c69803dada336893640110cb87221bb01dcf"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/98c3c8fd0d4c560e0f8335b79c407bbf7fc9462c"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/a9391ff7a7c5f113d6f2bf6621d49110950de49c"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/da3c256e2d0ebc87c7db0c605c9692b6f1722074"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/f836f9ac95df15f1e0af4beb0ec20021e8c91998"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/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.




Tags
Taxonomy of the tags.




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