cve-2024-40950
Vulnerability from cvelistv5
Published
2024-07-12 12:31
Modified
2024-11-05 09:33
Severity ?
Summary
mm: huge_memory: fix misused mapping_large_folio_support() for anon folios
Impacted products
Vendor Product Version
Linux Linux Version: 6.9
Show details on NVD website


{
  "containers": {
    "adp": [
      {
        "providerMetadata": {
          "dateUpdated": "2024-08-02T04:39:55.883Z",
          "orgId": "af854a3a-2127-422b-91ae-364da2661108",
          "shortName": "CVE"
        },
        "references": [
          {
            "tags": [
              "x_transferred"
            ],
            "url": "https://git.kernel.org/stable/c/5df493a99fcf887133cf01d23cd4bebb6d385d3c"
          },
          {
            "tags": [
              "x_transferred"
            ],
            "url": "https://git.kernel.org/stable/c/6a50c9b512f7734bc356f4bd47885a6f7c98491a"
          }
        ],
        "title": "CVE Program Container"
      },
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2024-40950",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2024-09-10T17:04:01.869844Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2024-09-11T17:34:24.864Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "include/linux/pagemap.h",
            "mm/huge_memory.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "5df493a99fcf",
              "status": "affected",
              "version": "c010d47f107f",
              "versionType": "git"
            },
            {
              "lessThan": "6a50c9b512f7",
              "status": "affected",
              "version": "c010d47f107f",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "include/linux/pagemap.h",
            "mm/huge_memory.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "6.9"
            },
            {
              "lessThan": "6.9",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.9.*",
              "status": "unaffected",
              "version": "6.9.7",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "6.10",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm: huge_memory: fix misused mapping_large_folio_support() for anon folios\n\nWhen I did a large folios split test, a WARNING \"[ 5059.122759][ T166]\nCannot split file folio to non-0 order\" was triggered.  But the test cases\nare only for anonmous folios.  while mapping_large_folio_support() is only\nreasonable for page cache folios.\n\nIn split_huge_page_to_list_to_order(), the folio passed to\nmapping_large_folio_support() maybe anonmous folio.  The folio_test_anon()\ncheck is missing.  So the split of the anonmous THP is failed.  This is\nalso the same for shmem_mapping().  We\u0027d better add a check for both.  But\nthe shmem_mapping() in __split_huge_page() is not involved, as for\nanonmous folios, the end parameter is set to -1, so (head[i].index \u003e= end)\nis always false.  shmem_mapping() is not called.\n\nAlso add a VM_WARN_ON_ONCE() in mapping_large_folio_support() for anon\nmapping, So we can detect the wrong use more easily.\n\nTHP folios maybe exist in the pagecache even the file system doesn\u0027t\nsupport large folio, it is because when CONFIG_TRANSPARENT_HUGEPAGE is\nenabled, khugepaged will try to collapse read-only file-backed pages to\nTHP.  But the mapping does not actually support multi order large folios\nproperly.\n\nUsing /sys/kernel/debug/split_huge_pages to verify this, with this patch,\nlarge anon THP is successfully split and the warning is ceased."
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2024-11-05T09:33:46.314Z",
        "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "shortName": "Linux"
      },
      "references": [
        {
          "url": "https://git.kernel.org/stable/c/5df493a99fcf887133cf01d23cd4bebb6d385d3c"
        },
        {
          "url": "https://git.kernel.org/stable/c/6a50c9b512f7734bc356f4bd47885a6f7c98491a"
        }
      ],
      "title": "mm: huge_memory: fix misused mapping_large_folio_support() for anon folios",
      "x_generator": {
        "engine": "bippy-9e1c9544281a"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
    "assignerShortName": "Linux",
    "cveId": "CVE-2024-40950",
    "datePublished": "2024-07-12T12:31:54.815Z",
    "dateReserved": "2024-07-12T12:17:45.591Z",
    "dateUpdated": "2024-11-05T09:33:46.314Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.1",
  "meta": {
    "nvd": "{\"cve\":{\"id\":\"CVE-2024-40950\",\"sourceIdentifier\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"published\":\"2024-07-12T13:15:17.353\",\"lastModified\":\"2024-11-21T09:31:55.947\",\"vulnStatus\":\"Awaiting Analysis\",\"cveTags\":[],\"descriptions\":[{\"lang\":\"en\",\"value\":\"In the Linux kernel, the following vulnerability has been resolved:\\n\\nmm: huge_memory: fix misused mapping_large_folio_support() for anon folios\\n\\nWhen I did a large folios split test, a WARNING \\\"[ 5059.122759][ T166]\\nCannot split file folio to non-0 order\\\" was triggered.  But the test cases\\nare only for anonmous folios.  while mapping_large_folio_support() is only\\nreasonable for page cache folios.\\n\\nIn split_huge_page_to_list_to_order(), the folio passed to\\nmapping_large_folio_support() maybe anonmous folio.  The folio_test_anon()\\ncheck is missing.  So the split of the anonmous THP is failed.  This is\\nalso the same for shmem_mapping().  We\u0027d better add a check for both.  But\\nthe shmem_mapping() in __split_huge_page() is not involved, as for\\nanonmous folios, the end parameter is set to -1, so (head[i].index \u003e= end)\\nis always false.  shmem_mapping() is not called.\\n\\nAlso add a VM_WARN_ON_ONCE() in mapping_large_folio_support() for anon\\nmapping, So we can detect the wrong use more easily.\\n\\nTHP folios maybe exist in the pagecache even the file system doesn\u0027t\\nsupport large folio, it is because when CONFIG_TRANSPARENT_HUGEPAGE is\\nenabled, khugepaged will try to collapse read-only file-backed pages to\\nTHP.  But the mapping does not actually support multi order large folios\\nproperly.\\n\\nUsing /sys/kernel/debug/split_huge_pages to verify this, with this patch,\\nlarge anon THP is successfully split and the warning is ceased.\"},{\"lang\":\"es\",\"value\":\"En el kernel de Linux, se resolvi\u00f3 la siguiente vulnerabilidad: mm: enorme_memoria: corrige el mapeo_grande_folio_support() mal utilizado para publicaciones an\u00f3nimas Cuando hice una prueba de divisi\u00f3n de publicaciones grandes, apareci\u00f3 una ADVERTENCIA \\\"[ 5059.122759][ T166] No se puede dividir la publicaci\u00f3n del archivo en un valor distinto de 0 \\\"orden\\\" se activ\u00f3. Pero los casos de prueba son s\u00f3lo para folios an\u00f3nimos. mientras que mapping_large_folio_support() solo es razonable para las publicaciones de cach\u00e9 de p\u00e1ginas. En split_huge_page_to_list_to_order(), la publicaci\u00f3n pas\u00f3 a mapping_large_folio_support(), tal vez una publicaci\u00f3n an\u00f3nima. Falta la verificaci\u00f3n folio_test_anon(). As\u00ed que la divisi\u00f3n del THP an\u00f3nimo fracas\u00f3. Esto tambi\u00e9n es lo mismo para shmem_mapping(). Ser\u00e1 mejor que agreguemos un cheque para ambos. Pero shmem_mapping() en __split_huge_page() no est\u00e1 involucrado, ya que para las publicaciones an\u00f3nimas, el par\u00e1metro final se establece en -1, por lo que (head[i].index \u0026gt;= end) siempre es falso. shmem_mapping() no se llama. Tambi\u00e9n agregue un VM_WARN_ON_ONCE() en mapping_large_folio_support() para un mapeo an\u00f3nimo, para que podamos detectar el uso incorrecto m\u00e1s f\u00e1cilmente. Es posible que existan publicaciones de THP en el cach\u00e9 de p\u00e1ginas, incluso si el sistema de archivos no admite publicaciones grandes, esto se debe a que cuando CONFIG_TRANSPARENT_HUGEPAGE est\u00e1 habilitado, khugepaged intentar\u00e1 colapsar las p\u00e1ginas respaldadas por archivos de solo lectura en THP. Pero el mapeo en realidad no admite correctamente folios grandes de varios pedidos. Usando /sys/kernel/debug/split_huge_pages para verificar esto, con este parche, un THP an\u00f3nimo grande se divide con \u00e9xito y la advertencia cesa.\"}],\"metrics\":{},\"references\":[{\"url\":\"https://git.kernel.org/stable/c/5df493a99fcf887133cf01d23cd4bebb6d385d3c\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/6a50c9b512f7734bc356f4bd47885a6f7c98491a\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/5df493a99fcf887133cf01d23cd4bebb6d385d3c\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\"},{\"url\":\"https://git.kernel.org/stable/c/6a50c9b512f7734bc356f4bd47885a6f7c98491a\",\"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.