Wind River Support Network

Description

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