{"dataType": "CVE_RECORD", "dataVersion": "5.1", "cveMetadata": {"cveId": "CVE-2024-40950", "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "state": "PUBLISHED", "assignerShortName": "Linux", "dateReserved": "2024-07-12T12:17:45.591Z", "datePublished": "2024-07-12T12:31:54.815Z", "dateUpdated": "2024-11-05T09:33:46.314Z"}, "containers": {"cna": {"providerMetadata": {"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "shortName": "Linux", "dateUpdated": "2024-11-05T09:33:46.314Z"}, "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'd 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 >= 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't\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."}], "affected": [{"product": "Linux", "vendor": "Linux", "defaultStatus": "unaffected", "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git", "programFiles": ["include/linux/pagemap.h", "mm/huge_memory.c"], "versions": [{"version": "c010d47f107f", "lessThan": "5df493a99fcf", "status": "affected", "versionType": "git"}, {"version": "c010d47f107f", "lessThan": "6a50c9b512f7", "status": "affected", "versionType": "git"}]}, {"product": "Linux", "vendor": "Linux", "defaultStatus": "affected", "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git", "programFiles": ["include/linux/pagemap.h", "mm/huge_memory.c"], "versions": [{"version": "6.9", "status": "affected"}, {"version": "0", "lessThan": "6.9", "status": "unaffected", "versionType": "semver"}, {"version": "6.9.7", "lessThanOrEqual": "6.9.*", "status": "unaffected", "versionType": "semver"}, {"version": "6.10", "lessThanOrEqual": "*", "status": "unaffected", "versionType": "original_commit_for_fix"}]}], "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"}}, "adp": [{"providerMetadata": {"orgId": "af854a3a-2127-422b-91ae-364da2661108", "shortName": "CVE", "dateUpdated": "2024-08-02T04:39:55.883Z"}, "title": "CVE Program Container", "references": [{"url": "https://git.kernel.org/stable/c/5df493a99fcf887133cf01d23cd4bebb6d385d3c", "tags": ["x_transferred"]}, {"url": "https://git.kernel.org/stable/c/6a50c9b512f7734bc356f4bd47885a6f7c98491a", "tags": ["x_transferred"]}]}, {"metrics": [{"other": {"type": "ssvc", "content": {"id": "CVE-2024-40950", "role": "CISA Coordinator", "options": [{"Exploitation": "none"}, {"Automatable": "no"}, {"Technical Impact": "partial"}], "version": "2.0.3", "timestamp": "2024-09-10T17:04:01.869844Z"}}}], "title": "CISA ADP Vulnrichment", "providerMetadata": {"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0", "shortName": "CISA-ADP", "dateUpdated": "2024-09-11T17:34:24.864Z"}}]}}

{"dataType": "CVE_RECORD", "containers": {"adp": [{"title": "CVE Program Container", "references": [{"url": "https://git.kernel.org/stable/c/5df493a99fcf887133cf01d23cd4bebb6d385d3c", "tags": ["x_transferred"]}, {"url": "https://git.kernel.org/stable/c/6a50c9b512f7734bc356f4bd47885a6f7c98491a", "tags": ["x_transferred"]}], "providerMetadata": {"orgId": "af854a3a-2127-422b-91ae-364da2661108", "shortName": "CVE", "dateUpdated": "2024-08-02T04:39:55.883Z"}}, {"title": "CISA ADP Vulnrichment", "metrics": [{"other": {"type": "ssvc", "content": {"id": "CVE-2024-40950", "role": "CISA Coordinator", "options": [{"Exploitation": "none"}, {"Automatable": "no"}, {"Technical Impact": "partial"}], "version": "2.0.3", "timestamp": "2024-09-10T17:04:01.869844Z"}}}], "providerMetadata": {"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0", "shortName": "CISA-ADP", "dateUpdated": "2024-09-11T12:42:22.496Z"}}], "cna": {"title": "mm: huge_memory: fix misused mapping_large_folio_support() for anon folios", "affected": [{"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git", "vendor": "Linux", "product": "Linux", "versions": [{"status": "affected", "version": "c010d47f107f", "lessThan": "5df493a99fcf", "versionType": "git"}, {"status": "affected", "version": "c010d47f107f", "lessThan": "6a50c9b512f7", "versionType": "git"}], "programFiles": ["include/linux/pagemap.h", "mm/huge_memory.c"], "defaultStatus": "unaffected"}, {"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git", "vendor": "Linux", "product": "Linux", "versions": [{"status": "affected", "version": "6.9"}, {"status": "unaffected", "version": "0", "lessThan": "6.9", "versionType": "semver"}, {"status": "unaffected", "version": "6.9.7", "versionType": "semver", "lessThanOrEqual": "6.9.*"}, {"status": "unaffected", "version": "6.10", "versionType": "original_commit_for_fix", "lessThanOrEqual": "*"}], "programFiles": ["include/linux/pagemap.h", "mm/huge_memory.c"], "defaultStatus": "affected"}], "references": [{"url": "https://git.kernel.org/stable/c/5df493a99fcf887133cf01d23cd4bebb6d385d3c"}, {"url": "https://git.kernel.org/stable/c/6a50c9b512f7734bc356f4bd47885a6f7c98491a"}], "x_generator": {"engine": "bippy-9e1c9544281a"}, "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'd 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 >= 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't\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": {"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "shortName": "Linux", "dateUpdated": "2024-11-05T09:33:46.314Z"}}}, "cveMetadata": {"cveId": "CVE-2024-40950", "state": "PUBLISHED", "dateUpdated": "2024-11-05T09:33:46.314Z", "dateReserved": "2024-07-12T12:17:45.591Z", "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "datePublished": "2024-07-12T12:31:54.815Z", "assignerShortName": "Linux"}, "dataVersion": "5.1"}

{"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'd 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 >= 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't\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 >= 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."}], "id": "CVE-2024-40950", "lastModified": "2024-07-12T16:34:58.687", "metrics": {}, "published": "2024-07-12T13:15:17.353", "references": [{"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "url": "https://git.kernel.org/stable/c/5df493a99fcf887133cf01d23cd4bebb6d385d3c"}, {"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "url": "https://git.kernel.org/stable/c/6a50c9b512f7734bc356f4bd47885a6f7c98491a"}], "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "vulnStatus": "Awaiting Analysis"}

{"bugzilla": {"description": "kernel: mm: huge_memory: fix misused mapping_large_folio_support() for anon folios", "id": "2297534", "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2297534"}, "csaw": false, "cvss3": {"cvss3_base_score": "5.5", "cvss3_scoring_vector": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H", "status": "draft"}, "cwe": "CWE-99", "details": ["In the Linux kernel, the following vulnerability has been resolved:\nmm: huge_memory: fix misused mapping_large_folio_support() for anon folios\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.\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'd 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 >= end)\nis always false. shmem_mapping() is not called.\nAlso add a VM_WARN_ON_ONCE() in mapping_large_folio_support() for anon\nmapping, So we can detect the wrong use more easily.\nTHP folios maybe exist in the pagecache even the file system doesn't\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.\nUsing /sys/kernel/debug/split_huge_pages to verify this, with this patch,\nlarge anon THP is successfully split and the warning is ceased.", "A vulnerability was found in the Linux kernel related to \"mm: huge_memory: fix misused mapping_large_folio_support() for anon folios\". This issue was resolved by adding checks to prevent the incorrect use of `mapping_large_folio_support()` for anonymous folios. The flaw caused split failures and warnings during large anonymous folio operations, as the function is only suitable for page cache folios."], "mitigation": {"lang": "en:us", "value": "Mitigation for this issue is either not available or the currently available options do not meet the Red Hat Product Security criteria comprising ease of use and deployment, applicability to widespread installation base or stability."}, "name": "CVE-2024-40950", "package_state": [{"cpe": "cpe:/o:redhat:enterprise_linux:6", "fix_state": "Not affected", "package_name": "kernel", "product_name": "Red Hat Enterprise Linux 6"}, {"cpe": "cpe:/o:redhat:enterprise_linux:7", "fix_state": "Out of support scope", "package_name": "kernel", "product_name": "Red Hat Enterprise Linux 7"}, {"cpe": "cpe:/o:redhat:enterprise_linux:7", "fix_state": "Out of support scope", "package_name": "kernel-rt", "product_name": "Red Hat Enterprise Linux 7"}, {"cpe": "cpe:/o:redhat:enterprise_linux:8", "fix_state": "Not affected", "package_name": "kernel", "product_name": "Red Hat Enterprise Linux 8"}, {"cpe": "cpe:/o:redhat:enterprise_linux:8", "fix_state": "Not affected", "package_name": "kernel-rt", "product_name": "Red Hat Enterprise Linux 8"}, {"cpe": "cpe:/o:redhat:enterprise_linux:9", "fix_state": "Not affected", "package_name": "kernel", "product_name": "Red Hat Enterprise Linux 9"}, {"cpe": "cpe:/o:redhat:enterprise_linux:9", "fix_state": "Not affected", "package_name": "kernel-rt", "product_name": "Red Hat Enterprise Linux 9"}], "public_date": "2024-07-12T00:00:00Z", "references": ["https://www.cve.org/CVERecord?id=CVE-2024-40950\nhttps://nvd.nist.gov/vuln/detail/CVE-2024-40950\nhttps://lore.kernel.org/linux-cve-announce/2024071222-CVE-2024-40950-6155@gregkh/T"], "statement": "Red Hat Enterprise Linux is not vulnerable to this CVE, as it does not affect the versions or configurations of the Linux kernel used in its distributions.", "threat_severity": "Moderate", "upstream_fix": "kernel 6.9.7, kernel 6.10-rc5"}