CVE-2024-40950

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm: huge_memory: fix misused mapping_large_folio_support() for anon folios<br /> <br /> When I did a large folios split test, a WARNING "[ 5059.122759][ T166]<br /> Cannot split file folio to non-0 order" was triggered. But the test cases<br /> are only for anonmous folios. while mapping_large_folio_support() is only<br /> reasonable for page cache folios.<br /> <br /> In split_huge_page_to_list_to_order(), the folio passed to<br /> mapping_large_folio_support() maybe anonmous folio. The folio_test_anon()<br /> check is missing. So the split of the anonmous THP is failed. This is<br /> also the same for shmem_mapping(). We&amp;#39;d better add a check for both. But<br /> the shmem_mapping() in __split_huge_page() is not involved, as for<br /> anonmous folios, the end parameter is set to -1, so (head[i].index &gt;= end)<br /> is always false. shmem_mapping() is not called.<br /> <br /> Also add a VM_WARN_ON_ONCE() in mapping_large_folio_support() for anon<br /> mapping, So we can detect the wrong use more easily.<br /> <br /> THP folios maybe exist in the pagecache even the file system doesn&amp;#39;t<br /> support large folio, it is because when CONFIG_TRANSPARENT_HUGEPAGE is<br /> enabled, khugepaged will try to collapse read-only file-backed pages to<br /> THP. But the mapping does not actually support multi order large folios<br /> properly.<br /> <br /> Using /sys/kernel/debug/split_huge_pages to verify this, with this patch,<br /> large anon THP is successfully split and the warning is ceased.