CVE-2024-27005
Vulnerability from cvelistv5
Published
2024-05-01 05:28
Modified
2024-12-19 08:52
Summary
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(... <r = invalid pointer> 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(... <r = invalid pointer> 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")
Impacted products
Vendor Product Version
Linux Linux Version: 6.6
Show details on NVD website


{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "cvssV3_1": {
              "attackComplexity": "HIGH",
              "attackVector": "LOCAL",
              "availabilityImpact": "HIGH",
              "baseScore": 6.3,
              "baseSeverity": "MEDIUM",
              "confidentialityImpact": "HIGH",
              "integrityImpact": "NONE",
              "privilegesRequired": "LOW",
              "scope": "UNCHANGED",
              "userInteraction": "NONE",
              "vectorString": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:H",
              "version": "3.1"
            }
          },
          {
            "other": {
              "content": {
                "id": "CVE-2024-27005",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2024-06-06T18:46:13.449387Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "problemTypes": [
          {
            "descriptions": [
              {
                "description": "CWE-noinfo Not enough information",
                "lang": "en",
                "type": "CWE"
              }
            ]
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2024-11-05T15:17:57.462Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      },
      {
        "providerMetadata": {
          "dateUpdated": "2024-08-02T00:21:05.951Z",
          "orgId": "af854a3a-2127-422b-91ae-364da2661108",
          "shortName": "CVE"
        },
        "references": [
          {
            "tags": [
              "x_transferred"
            ],
            "url": "https://git.kernel.org/stable/c/d0d04efa2e367921654b5106cc5c05e3757c2b42"
          },
          {
            "tags": [
              "x_transferred"
            ],
            "url": "https://git.kernel.org/stable/c/4c65507121ea8e0b47fae6d2049c8688390d46b6"
          },
          {
            "tags": [
              "x_transferred"
            ],
            "url": "https://git.kernel.org/stable/c/de1bf25b6d771abdb52d43546cf57ad775fb68a1"
          }
        ],
        "title": "CVE Program Container"
      }
    ],
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "drivers/interconnect/core.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "d0d04efa2e367921654b5106cc5c05e3757c2b42",
              "status": "affected",
              "version": "af42269c3523492d71ebbe11fefae2653e9cdc78",
              "versionType": "git"
            },
            {
              "lessThan": "4c65507121ea8e0b47fae6d2049c8688390d46b6",
              "status": "affected",
              "version": "af42269c3523492d71ebbe11fefae2653e9cdc78",
              "versionType": "git"
            },
            {
              "lessThan": "de1bf25b6d771abdb52d43546cf57ad775fb68a1",
              "status": "affected",
              "version": "af42269c3523492d71ebbe11fefae2653e9cdc78",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "drivers/interconnect/core.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "6.6"
            },
            {
              "lessThan": "6.6",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.6.*",
              "status": "unaffected",
              "version": "6.6.29",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.8.*",
              "status": "unaffected",
              "version": "6.8.8",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "6.9",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "In the Linux kernel, the following vulnerability has been resolved:\n\ninterconnect: Don\u0027t access req_list while it\u0027s 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\u0027t 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(\u0026icc_bw_lock);\n                                     icc_put(path_b)\n                                       mutex_lock(\u0026icc_lock);\n    aggregate_requests()\n      hlist_for_each_entry(r, ...\n                                       hlist_del(...\n        \u003cr = invalid pointer\u003e\n\nExample B:\n\n  CPU0                               CPU1\n  ----                               ----\n  icc_set_bw(path_a)\n    mutex_lock(\u0026icc_bw_lock);\n                                     path_b = of_icc_get()\n                                       of_icc_get_by_index()\n                                         mutex_lock(\u0026icc_lock);\n                                         path_find()\n                                           path_init()\n    aggregate_requests()\n      hlist_for_each_entry(r, ...\n                                             hlist_add_head(...\n        \u003cr = invalid pointer\u003e\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\u0027t\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\")"
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2024-12-19T08:52:20.679Z",
        "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "shortName": "Linux"
      },
      "references": [
        {
          "url": "https://git.kernel.org/stable/c/d0d04efa2e367921654b5106cc5c05e3757c2b42"
        },
        {
          "url": "https://git.kernel.org/stable/c/4c65507121ea8e0b47fae6d2049c8688390d46b6"
        },
        {
          "url": "https://git.kernel.org/stable/c/de1bf25b6d771abdb52d43546cf57ad775fb68a1"
        }
      ],
      "title": "interconnect: Don\u0027t access req_list while it\u0027s being manipulated",
      "x_generator": {
        "engine": "bippy-5f407fcff5a0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
    "assignerShortName": "Linux",
    "cveId": "CVE-2024-27005",
    "datePublished": "2024-05-01T05:28:59.193Z",
    "dateReserved": "2024-02-19T14:20:24.207Z",
    "dateUpdated": "2024-12-19T08:52:20.679Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.1",
  "vulnerability-lookup:meta": {
    "nvd": "{\"cve\":{\"id\":\"CVE-2024-27005\",\"sourceIdentifier\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"published\":\"2024-05-01T06:15:18.883\",\"lastModified\":\"2024-11-21T09:03:36.110\",\"vulnStatus\":\"Awaiting Analysis\",\"cveTags\":[],\"descriptions\":[{\"lang\":\"en\",\"value\":\"In the Linux kernel, the following vulnerability has been resolved:\\n\\ninterconnect: Don\u0027t access req_list while it\u0027s 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\u0027t 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(\u0026icc_bw_lock);\\n                                     icc_put(path_b)\\n                                       mutex_lock(\u0026icc_lock);\\n    aggregate_requests()\\n      hlist_for_each_entry(r, ...\\n                                       hlist_del(...\\n        \u003cr = invalid pointer\u003e\\n\\nExample B:\\n\\n  CPU0                               CPU1\\n  ----                               ----\\n  icc_set_bw(path_a)\\n    mutex_lock(\u0026icc_bw_lock);\\n                                     path_b = of_icc_get()\\n                                       of_icc_get_by_index()\\n                                         mutex_lock(\u0026icc_lock);\\n                                         path_find()\\n                                           path_init()\\n    aggregate_requests()\\n      hlist_for_each_entry(r, ...\\n                                             hlist_add_head(...\\n        \u003cr = invalid pointer\u003e\\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\u0027t\\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\\\")\"},{\"lang\":\"es\",\"value\":\"En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: interconexi\u00f3n: no acceder a req_list mientras se est\u00e1 manipulando. El mutex icc_lock se dividi\u00f3 en mutex icc_lock e icc_bw_lock separados en [1] para evitar s\u00edmbolos de bloqueo. Sin embargo, esto no protegi\u00f3 adecuadamente el acceso a icc_node::req_list. La funci\u00f3n icc_set_bw() eventualmente iterar\u00e1 sobre req_list mientras solo mantiene icc_bw_lock, pero req_list se puede modificar mientras solo mantiene icc_lock. Esto provoca ejecuci\u00f3ns entre icc_set_bw(), of_icc_get() e icc_put(). Ejemplo A: CPU0 CPU1 ---- ---- icc_set_bw(path_a) mutex_lock(\u0026amp;icc_bw_lock); icc_put(ruta_b) mutex_lock(\u0026amp;icc_lock); agregado_requests() hlist_for_each_entry(r, ... hlist_del(...  Ejemplo B: CPU0 CPU1 ---- ---- icc_set_bw(path_a) mutex_lock(\u0026amp;icc_bw_lock); path_b = of_icc_get() of_icc_get_by_index( ) mutex_lock(\u0026amp;icc_lock); path_find() path_init() agregado_requests() hlist_for_each_entry(r, ... hlist_add_head(...  Solucione este problema asegur\u00e1ndose de que icc_bw_lock siempre se mantenga antes de manipular icc_node::req_list. El adicional Los lugares donde se mantiene icc_bw_lock no realizan ninguna asignaci\u00f3n de memoria, por lo que a\u00fan deber\u00edamos estar a salvo de los s\u00edmbolos de bloqueo originales que motivaron los bloqueos separados [1] commit af42269c3523 (\\\"interconexi\u00f3n: arreglar el bloqueo para runpm vs reclaim\\\")\"}],\"metrics\":{\"cvssMetricV31\":[{\"source\":\"134c704f-9b21-4f2e-91b3-4a467353bcc0\",\"type\":\"Secondary\",\"cvssData\":{\"version\":\"3.1\",\"vectorString\":\"CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:H\",\"baseScore\":6.3,\"baseSeverity\":\"MEDIUM\",\"attackVector\":\"LOCAL\",\"attackComplexity\":\"HIGH\",\"privilegesRequired\":\"LOW\",\"userInteraction\":\"NONE\",\"scope\":\"UNCHANGED\",\"confidentialityImpact\":\"HIGH\",\"integrityImpact\":\"NONE\",\"availabilityImpact\":\"HIGH\"},\"exploitabilityScore\":1.0,\"impactScore\":5.2}]},\"references\":[{\"url\":\"https://git.kernel.org/stable/c/4c65507121ea8e0b47fae6d2049c8688390d46b6\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/d0d04efa2e367921654b5106cc5c05e3757c2b42\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/de1bf25b6d771abdb52d43546cf57ad775fb68a1\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/4c65507121ea8e0b47fae6d2049c8688390d46b6\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\"},{\"url\":\"https://git.kernel.org/stable/c/d0d04efa2e367921654b5106cc5c05e3757c2b42\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\"},{\"url\":\"https://git.kernel.org/stable/c/de1bf25b6d771abdb52d43546cf57ad775fb68a1\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\"}]}}"
  }
}


Log in or create an account to share your comment.




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.