CVE-2025-40006

In the Linux kernel, the following vulnerability has been resolved:

mm/hugetlb: fix folio is still mapped when deleted

Migration may be raced with fallocating hole. removeinodesinglefolio will unmap the folio if the folio is still mapped. However, it's called without folio lock. If the folio is migrated and the mapped pte has been converted to migration entry, foliomapped() returns false, and won't unmap it. Due to extra refcount held by removeinodesinglefolio, migration fails, restores migration entry to normal pte, and the folio is mapped again. As a result, we triggered BUG in filemapunaccount_folio.

The log is as follows: BUG: Bad page cache in process hugetlb pfn:156c00 page: refcount:515 mapcount:0 mapping:0000000099fef6e1 index:0x0 pfn:0x156c00 head: order:9 mapcount:1 entiremapcount:1 nrpagesmapped:0 pincount:0 aops:hugetlbfsaops ino:dcc dentry name(?):"myhugepagefile" flags: 0x17ffffc00000c1(locked|waiters|head|node=0|zone=2|lastcpupid=0x1fffff) pagetype: f4(hugetlb) page dumped because: still mapped when deleted CPU: 1 UID: 0 PID: 395 Comm: hugetlb Not tainted 6.17.0-rc5-00044-g7aac71907bde-dirty #484 NONE Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 0.0.0 02/06/2015 Call Trace: <TASK> dumpstacklvl+0x4f/0x70 filemapunaccount_folio+0xc4/0x1c0 __filemapremovefolio+0x38/0x1c0 filemapremovefolio+0x41/0xd0 removeinodehugepages+0x142/0x250 hugetlbfsfallocate+0x471/0x5a0 vfsfallocate+0x149/0x380

Hold folio lock before checking if the folio is mapped to avold race with migration.