CVE-2024-57881 — mm/page_alloc: don't call pfn_to_page() on possibly non-existent PFN in split_large_buddy()

Affected: Linux

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

mm/page_alloc: don't call pfn_to_page() on possibly non-existent PFN in split_large_buddy()

In split_large_buddy(), we might call pfn_to_page() on a PFN that might not exist. In corner cases, such as when freeing the highest pageblock in the last memory section, this could result with CONFIG_SPARSEMEM && !CONFIG_SPARSEMEM_EXTREME in __pfn_to_section() returning NULL and and __section_mem_map_addr() dereferencing that NULL pointer.

Let's fix it, and avoid doing a pfn_to_page() call for the first iteration, where we already have the page.

So far this was found by code inspection, but let's just CC stable as the fix is easy.

Most recent entries from all

CVE-2024-57881 — mm/page_alloc: don't call pfn_to_page() on possibly non-existent PFN in split_large_buddy()