In the Linux kernel, the following vulnerability has been resolved:
mm/filemap: fix filemapgetfolios_contig THP panic
Patch series "memfd-pin huge page fixes".
Fix multiple bugs that occur when using memfdpinfolios with hugetlb pages and THP. The hugetlb bugs only bite when the page is not yet faulted in when memfdpinfolios is called. The THP bug bites when the starting offset passed to memfdpinfolios is not huge page aligned. See the commit messages for details.
This patch (of 5):
memfdpinfolios on memory backed by THP panics if the requested start offset is not huge page aligned:
BUG: kernel NULL pointer dereference, address: 0000000000000036 RIP: 0010:filemapgetfolios_contig+0xdf/0x290 RSP: 0018:ffffc9002092fbe8 EFLAGS: 00010202 RAX: 0000000000000002 RBX: 0000000000000002 RCX: 0000000000000002
The fault occurs here, because xas_load returns a folio with value 2:
filemap_get_folios_contig()
for (folio = xas_load(&xas); folio && xas.xa_index <= end;
folio = xas_next(&xas)) {
...
if (!folio_try_get(folio)) <-- BOOM
"2" is an xarray sibling entry. We get it because memfdpinfolios does not round the indices passed to filemapgetfolioscontig to huge page boundaries for THP, so we load from the middle of a huge page range see a sibling. (It does round for hugetlbfs, at the isfile_hugepages test).
To fix, if the folio is a sibling, then return the next index as the starting point for the next call to filemapgetfolios_contig.