]> git.ipfire.org Git - thirdparty/kernel/stable.git/commit
mm/page_alloc: don't call pfn_to_page() on possibly non-existent PFN in split_large_b...
authorDavid Hildenbrand <david@redhat.com>
Tue, 10 Dec 2024 09:34:37 +0000 (10:34 +0100)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Fri, 27 Dec 2024 13:02:13 +0000 (14:02 +0100)
commit4234ca9884bcae9e48ed38652d91696ad5cd591d
treefdf3337542633cf50a879ca50a25f53cb22c9d38
parentad7c9f1f4322ba9a9f5c5c37dcebc587eeba89f1
mm/page_alloc: don't call pfn_to_page() on possibly non-existent PFN in split_large_buddy()

commit faeec8e23c10bd30e8aa759a2eb3018dae00f924 upstream.

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.

Link: https://lkml.kernel.org/r/20241210093437.174413-1-david@redhat.com
Fixes: fd919a85cd55 ("mm: page_isolation: prepare for hygienic freelists")
Signed-off-by: David Hildenbrand <david@redhat.com>
Reported-by: Vlastimil Babka <vbabka@suse.cz>
Closes: https://lkml.kernel.org/r/e1a898ba-a717-4d20-9144-29df1a6c8813@suse.cz
Reviewed-by: Vlastimil Babka <vbabka@suse.cz>
Reviewed-by: Zi Yan <ziy@nvidia.com>
Acked-by: Johannes Weiner <hannes@cmpxchg.org>
Cc: Yu Zhao <yuzhao@google.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
mm/page_alloc.c