CVE-2025-40006

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/hugetlb: fix folio is still mapped when deleted<br /> <br /> Migration may be raced with fallocating hole. remove_inode_single_folio<br /> will unmap the folio if the folio is still mapped. However, it&amp;#39;s called<br /> without folio lock. If the folio is migrated and the mapped pte has been<br /> converted to migration entry, folio_mapped() returns false, and won&amp;#39;t<br /> unmap it. Due to extra refcount held by remove_inode_single_folio,<br /> migration fails, restores migration entry to normal pte, and the folio is<br /> mapped again. As a result, we triggered BUG in filemap_unaccount_folio.<br /> <br /> The log is as follows:<br /> BUG: Bad page cache in process hugetlb pfn:156c00<br /> page: refcount:515 mapcount:0 mapping:0000000099fef6e1 index:0x0 pfn:0x156c00<br /> head: order:9 mapcount:1 entire_mapcount:1 nr_pages_mapped:0 pincount:0<br /> aops:hugetlbfs_aops ino:dcc dentry name(?):"my_hugepage_file"<br /> flags: 0x17ffffc00000c1(locked|waiters|head|node=0|zone=2|lastcpupid=0x1fffff)<br /> page_type: f4(hugetlb)<br /> page dumped because: still mapped when deleted<br /> CPU: 1 UID: 0 PID: 395 Comm: hugetlb Not tainted 6.17.0-rc5-00044-g7aac71907bde-dirty #484 NONE<br /> Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 0.0.0 02/06/2015<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x4f/0x70<br /> filemap_unaccount_folio+0xc4/0x1c0<br /> __filemap_remove_folio+0x38/0x1c0<br /> filemap_remove_folio+0x41/0xd0<br /> remove_inode_hugepages+0x142/0x250<br /> hugetlbfs_fallocate+0x471/0x5a0<br /> vfs_fallocate+0x149/0x380<br /> <br /> Hold folio lock before checking if the folio is mapped to avold race with<br /> migration.