mm：huge_memory：修复匿名作品集的误用mapping_large_folio_support()（CVE-2024-40950）

CVE编号

CVE-2024-40950

利用情况

暂无

补丁情况

N/A

披露时间

2024-07-12

漏洞描述

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.

解决建议

建议您更新当前系统或软件至最新版，完成漏洞的修复。

参考链接
https://git.kernel.org/stable/c/5df493a99fcf887133cf01d23cd4bebb6d385d3c
https://git.kernel.org/stable/c/6a50c9b512f7734bc356f4bd47885a6f7c98491a

受影响软件情况

#	类型	厂商	产品	版本	影响面
1
	运行在以下环境
	系统	debian_11	linux	*		Up to (excluding) 5.10.218-1
	运行在以下环境
	系统	debian_12	linux	*		Up to (excluding) 6.1.94-1

CVSS3评分 N/A

• 攻击路径 N/A
• 攻击复杂度 N/A
• 权限要求 N/A
• 影响范围 N/A
• 用户交互 N/A
• 可用性 N/A
• 保密性 N/A
• 完整性 N/A

N/A

CWE-ID	漏洞类型

Exp相关链接

- avd.aliyun.com