CVE-2024-40950
published 2024-07-12CVE-2024-40950: 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…
PriorityP420medium5.5CVSS 3.1
AVLACLPRLUINSUCNINAH
EPSS
0.21%
11.0th percentile
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.
Affected
8 ranges
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| debian | linux | < linux 6.9.7-1 (forky) | linux 6.9.7-1 (forky) |
| linux | linux | — | — |
| linux | linux | >= c010d47f107f609b9f4d6a103b6dfc53889049e9 < 5df493a99fcf887133cf01d23cd4bebb6d385d3c | 5df493a99fcf887133cf01d23cd4bebb6d385d3c |
| linux | linux | >= c010d47f107f609b9f4d6a103b6dfc53889049e9 < 6a50c9b512f7734bc356f4bd47885a6f7c98491a | 6a50c9b512f7734bc356f4bd47885a6f7c98491a |
| linux | linux_kernel | — | — |
| linux | linux_kernel | >= 0 < 6.9.7-1 | 6.9.7-1 |
| linux | linux_kernel | >= 0 < 6.9.7-1 | 6.9.7-1 |
| linux | linux_kernel | >= 6.9 < 6.9.7 | 6.9.7 |
CVSS provenance
nvdv3.15.5MEDIUMCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
osv5.5MEDIUM
vendor_debian5.5LOW
vendor_redhat5.5MEDIUM
Stop checking back — get the weekly exploitation signal.
Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.
GHSA
GHSA-qvp3-ffc6-xf43: In the Linux kernel, the following vulnerability has been resolved:
mm: huge_memory: fix misused mapping_large_folio_support() for anon folios
When
ghsa_unreviewed·2024-07-12
CVE-2024-40950 [MEDIUM] GHSA-qvp3-ffc6-xf43: In the Linux kernel, the following vulnerability has been resolved:
mm: huge_memory: fix misused mapping_large_folio_support() for anon folios
When
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[
OSV
CVE-2024-40950: In the Linux kernel, the following vulnerability has been resolved: mm: huge_memory: fix misused mapping_large_folio_support() for anon folios When I
osv·2024-07-12·CVSS 5.5
CVE-2024-40950 [MEDIUM] CVE-2024-40950: In the Linux kernel, the following vulnerability has been resolved: mm: huge_memory: fix misused mapping_large_folio_support() for anon folios When I
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].
Red Hat
kernel: mm: huge_memory: fix misused mapping_large_folio_support() for anon folios
vendor_redhat·2024-07-12·CVSS 5.5
CVE-2024-40950 [MEDIUM] CWE-99 kernel: mm: huge_memory: fix misused mapping_large_folio_support() for anon folios
kernel: mm: huge_memory: fix misused mapping_large_folio_support() for anon folios
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() i
Debian
CVE-2024-40950: linux - In the Linux kernel, the following vulnerability has been resolved: mm: huge_me...
vendor_debian·2024·CVSS 5.5
CVE-2024-40950 [MEDIUM] CVE-2024-40950: linux - In the Linux kernel, the following vulnerability has been resolved: mm: huge_me...
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].
No detection rules found.
No public exploits indexed.
No writeups or analysis indexed.
2024-07-12
Published