CVE-2024-40950 in Linux
요약
\~에 의해 VulDB • 2026. 06. 17.
리눅스 커널에서 다음 취약점이 해결되었습니다:
mm: huge_memory: 익명 folio에 대해 mapping_large_folio_support()의 오용 수정
대규모 folio 분할 테스트를 수행하는 동안 경고 "[ 5059.122759][ T166] Cannot split file folio to non-0 order"가 발생했습니다. 그러나 테스트 케이스는 익명 folio에 대한 것뿐입니다. mapping_large_folio_support()는 페이지 캐시 folio에 대해서만 적절합니다.
split_huge_page_to_list_to_order()에서 mapping_large_folio_support()에 전달되는 folio는 익명 folio일 수 있습니다. folio_test_anon() 확인이 누락되어 있습니다. 따라서 익명 THP의 분할이 실패합니다. shmem_mapping()의 경우도 동일합니다. 두 경우에 대해 확인을 추가하는 것이 좋습니다. 그러나 __split_huge_page() 내의 shmem_mapping()은 관련이 없습니다. 익명 folio의 경우 end 매개변수가 -1로 설정되므로 (head[i].index >= end)는 항상 거짓이기 때문입니다. shmem_mapping()은 호출되지 않습니다.
또한 익명 매핑에 대해 mapping_large_folio_support()에 VM_WARN_ON_ONCE()를 추가하여 잘못된 사용을 더 쉽게 감지할 수 있도록 합니다.
파일 시스템이 대규모 folio를 지원하지 않더라도 THP folio가 페이지 캐시에 존재할 수 있습니다. 이는 CONFIG_TRANSPARENT_HUGEPAGE가 활성화되면 khugepaged가 읽기 전용 파일 기반 페이지를 THP로 병합하려고 시도하기 때문입니다. 그러나 매핑은 실제로 다중 주문 대규모 folio를 제대로 지원하지 않습니다.
/sys/kernel/debug/split_huge_pages를 사용하여 이를 검증한 결과, 이 패치를 적용하면 대규모 익명 THP가 성공적으로 분할되고 경고가 중단됩니다.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.