CVE-2024-49873

mm/filemap: fix filemap_get_folios_contig THP panic

published October 21, 2024

CVSS
—
EPSS
0%
Percentile
9.6
In the wild
Unconfirmed
What it is

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

mm/filemap: fix filemap_get_folios_contig THP panic

Patch series "memfd-pin huge page fixes".

Fix multiple bugs that occur when using memfd_pin_folios with hugetlb

pages and THP. The hugetlb bugs only bite when the page is not yet

faulted in when memfd_pin_folios is called. The THP bug bites when the

starting offset passed to memfd_pin_folios is not huge page aligned. See

the commit messages for details.

This patch (of 5):

memfd_pin_folios 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:filemap_get_folios_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 memfd_pin_folios does

not round the indices passed to filemap_get_folios_contig 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 is_file_hugepages test).

To fix, if the folio is a sibling, then return the next index as the

starting point for the next call to filemap_get_folios_contig.

The record
Technical detail
CVSS
Not scored
CVSS v4.0
Not supplied
EPSS
0.00202 · 9.6th percentile
Published
2024-10-21T18:01Z
EPSS history
Timeline
  • 21 OCT 18:01Z
    mm/filemap: fix filemap_get_folios_contig THP panic
    cvelistv5