NULL Pointer Dereference Affecting kernel-devel package, versions *

Note: Versions mentioned in the description apply only to the upstream kernel-devel package and not the kernel-devel package as distributed by RHEL. See How to fix? for RHEL:7 relevant fixed versions and status.

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.

• https://access.redhat.com/security/cve/CVE-2024-49873
• https://git.kernel.org/stable/c/570dd14bfecf281fa467c80f8ec92b26370ee36a
• https://git.kernel.org/stable/c/c225c4f6056b46a8a5bf2ed35abf17a2d6887691