GHSA-QVP3-FFC6-XF43

Vulnerability from github – Published: 2024-07-12 15:31 – Updated: 2025-10-06 21:30
VLAI?
Details

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

mm: huge_memory: fix misused mapping_large_folio_support() for anon folios

When I did a large folios split test, a WARNING "[ 5059.122759][ T166] Cannot split file folio to non-0 order" was triggered. But the test cases are only for anonmous folios. while mapping_large_folio_support() is only reasonable for page cache folios.

In split_huge_page_to_list_to_order(), the folio passed to mapping_large_folio_support() maybe anonmous folio. The folio_test_anon() check is missing. So the split of the anonmous THP is failed. This is also the same for shmem_mapping(). We'd better add a check for both. But the shmem_mapping() in __split_huge_page() is not involved, as for anonmous folios, the end parameter is set to -1, so (head[i].index >= end) is always false. shmem_mapping() is not called.

Also add a VM_WARN_ON_ONCE() in mapping_large_folio_support() for anon mapping, So we can detect the wrong use more easily.

THP folios maybe exist in the pagecache even the file system doesn't support large folio, it is because when CONFIG_TRANSPARENT_HUGEPAGE is enabled, khugepaged will try to collapse read-only file-backed pages to THP. But the mapping does not actually support multi order large folios properly.

Using /sys/kernel/debug/split_huge_pages to verify this, with this patch, large anon THP is successfully split and the warning is ceased.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-40950"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-07-12T13:15:17Z",
    "severity": "MODERATE"
  },
  "details": "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.",
  "id": "GHSA-qvp3-ffc6-xf43",
  "modified": "2025-10-06T21:30:27Z",
  "published": "2024-07-12T15:31:28Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40950"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/5df493a99fcf887133cf01d23cd4bebb6d385d3c"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/6a50c9b512f7734bc356f4bd47885a6f7c98491a"
    }
  ],
  "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.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.


Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…