ghsa-p672-9qr7-4cmf
Vulnerability from github
Published
2024-05-01 06:31
Modified
2024-11-05 18:31
Severity ?
6.3 (Medium) - CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:H
Details

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

interconnect: Don't access req_list while it's being manipulated

The icc_lock mutex was split into separate icc_lock and icc_bw_lock mutexes in [1] to avoid lockdep splats. However, this didn't adequately protect access to icc_node::req_list.

The icc_set_bw() function will eventually iterate over req_list while only holding icc_bw_lock, but req_list can be modified while only holding icc_lock. This causes races between icc_set_bw(), of_icc_get(), and icc_put().

Example A:

CPU0 CPU1 ---- ---- icc_set_bw(path_a) mutex_lock(&icc_bw_lock); icc_put(path_b) mutex_lock(&icc_lock); aggregate_requests() hlist_for_each_entry(r, ... hlist_del(...

Example B:

CPU0 CPU1 ---- ---- icc_set_bw(path_a) mutex_lock(&icc_bw_lock); path_b = of_icc_get() of_icc_get_by_index() mutex_lock(&icc_lock); path_find() path_init() aggregate_requests() hlist_for_each_entry(r, ... hlist_add_head(...

Fix this by ensuring icc_bw_lock is always held before manipulating icc_node::req_list. The additional places icc_bw_lock is held don't perform any memory allocations, so we should still be safe from the original lockdep splats that motivated the separate locks.

[1] commit af42269c3523 ("interconnect: Fix locking for runpm vs reclaim")

Show details on source website

To clipboard 

{
   affected: [],
   aliases: [
      "CVE-2024-27005",
   ],
   database_specific: {
      cwe_ids: [
         "CWE-362",
      ],
      github_reviewed: false,
      github_reviewed_at: null,
      nvd_published_at: "2024-05-01T06:15:18Z",
      severity: "MODERATE",
   },
   details: "In the Linux kernel, the following vulnerability has been resolved:\n\ninterconnect: Don't access req_list while it's being manipulated\n\nThe icc_lock mutex was split into separate icc_lock and icc_bw_lock\nmutexes in [1] to avoid lockdep splats. However, this didn't adequately\nprotect access to icc_node::req_list.\n\nThe icc_set_bw() function will eventually iterate over req_list while\nonly holding icc_bw_lock, but req_list can be modified while only\nholding icc_lock. This causes races between icc_set_bw(), of_icc_get(),\nand icc_put().\n\nExample A:\n\n  CPU0                               CPU1\n  ----                               ----\n  icc_set_bw(path_a)\n    mutex_lock(&icc_bw_lock);\n                                     icc_put(path_b)\n                                       mutex_lock(&icc_lock);\n    aggregate_requests()\n      hlist_for_each_entry(r, ...\n                                       hlist_del(...\n        <r = invalid pointer>\n\nExample B:\n\n  CPU0                               CPU1\n  ----                               ----\n  icc_set_bw(path_a)\n    mutex_lock(&icc_bw_lock);\n                                     path_b = of_icc_get()\n                                       of_icc_get_by_index()\n                                         mutex_lock(&icc_lock);\n                                         path_find()\n                                           path_init()\n    aggregate_requests()\n      hlist_for_each_entry(r, ...\n                                             hlist_add_head(...\n        <r = invalid pointer>\n\nFix this by ensuring icc_bw_lock is always held before manipulating\nicc_node::req_list. The additional places icc_bw_lock is held don't\nperform any memory allocations, so we should still be safe from the\noriginal lockdep splats that motivated the separate locks.\n\n[1] commit af42269c3523 (\"interconnect: Fix locking for runpm vs reclaim\")",
   id: "GHSA-p672-9qr7-4cmf",
   modified: "2024-11-05T18:31:58Z",
   published: "2024-05-01T06:31:43Z",
   references: [
      {
         type: "ADVISORY",
         url: "https://nvd.nist.gov/vuln/detail/CVE-2024-27005",
      },
      {
         type: "WEB",
         url: "https://git.kernel.org/stable/c/4c65507121ea8e0b47fae6d2049c8688390d46b6",
      },
      {
         type: "WEB",
         url: "https://git.kernel.org/stable/c/d0d04efa2e367921654b5106cc5c05e3757c2b42",
      },
      {
         type: "WEB",
         url: "https://git.kernel.org/stable/c/de1bf25b6d771abdb52d43546cf57ad775fb68a1",
      },
      {
         type: "WEB",
         url: "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/4EZ6PJW7VOZ224TD7N4JZNU6KV32ZJ53",
      },
      {
         type: "WEB",
         url: "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/DAMSOZXJEPUOXW33WZYWCVAY7Z5S7OOY",
      },
      {
         type: "WEB",
         url: "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GCBZZEC7L7KTWWAS2NLJK6SO3IZIL4WW",
      },
   ],
   schema_version: "1.4.0",
   severity: [
      {
         score: "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/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.




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.