CVE-2024-40950

What it actually does

Missing folio_test_anon() check before calling mapping_large_folio_support() and shmem_mapping() inside split_huge_page_to_list_to_order() allows anonymous THPs to be incorrectly treated as file-backed, causing split failure and a 'Cannot split file folio to non-0 order' warning.

Why it matters to the business

Memory-intensive workloads on affected kernels may encounter unexpected warnings and failed THP splits, reducing efficiency of anonymous huge-page handling without immediate service disruption.

How an attack unfolds

A local process creates anonymous memory backed by transparent huge pages, then triggers a split via madvise or debugfs; the absent anon check routes the folio through file-mapping logic, failing the split and emitting the warning.

How to fix it

Upgrade the Linux kernel to version 6.9.7 or later, or apply commit 5df493a99fcf887133cf01d23cd4bebb6d385d3c in the stable tree; rebuild and reboot with the patched kernel.

How to confirm the fix worked

Confirm kernel version is 6.9.7 or newer; exercise /sys/kernel/debug/split_huge_pages on anonymous THPs and verify absence of the warning and successful splits.

Typical attack path

1. Allocate anonymous memory to obtain a THP folio
2. Invoke split_huge_page_to_list_to_order() directly or indirectly
3. Trigger the missing anon check path in mapping_large_folio_support()
4. Observe kernel warning and failed split operation

How to detect it

Search kernel logs and dmesg for the string 'Cannot split file folio to non-0 order' occurring during anonymous memory operations; correlate with processes using transparent huge pages.

What your security team should do

• Prioritize kernel upgrade on systems with CONFIG_TRANSPARENT_HUGEPAGE enabled
• Monitor kernel logs for the specific split warning until patches are deployed
• Test memory-management workloads after upgrade to confirm THP split behavior