← Back

CVE-2024-49873

nvd nist
Published: Oct 21, 2024Modified: Jun 17, 2026

JSON object

Loading...
5.5
Vector
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Exploitability: 1.8 / Impact: 3.6
Source: NVD

Description

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.

Affected (1)

Products: Linux: Linux Kernel
1 product
Linux Kernel
Configuration A
1 vulnerable
Vulnerable SoftwareAffected Versions
From 6.11 to 6.11.3

References (2)

Source: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
Patch
Source: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
Patch

Timeline

No history available yet.