{"uuid": "79ea1a42-b2de-493a-b4a9-056874717eec", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2024-57881", "type": "seen", "source": "https://t.me/cvedetector/15098", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-57881 - Linux Kernel \"pfn_to_page\" NULL Pointer Dereference Vulnerability in Buddy Allocator\", \n  \"Content\": \"CVE ID : CVE-2024-57881 \nPublished : Jan. 11, 2025, 4:15 p.m. | 42\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nmm/page_alloc: don't call pfn_to_page() on possibly non-existent PFN in split_large_buddy()  \n  \nIn split_large_buddy(), we might call pfn_to_page() on a PFN that might  \nnot exist.  In corner cases, such as when freeing the highest pageblock in  \nthe last memory section, this could result with CONFIG_SPARSEMEM &&  \n!CONFIG_SPARSEMEM_EXTREME in __pfn_to_section() returning NULL and and  \n__section_mem_map_addr() dereferencing that NULL pointer.  \n  \nLet's fix it, and avoid doing a pfn_to_page() call for the first  \niteration, where we already have the page.  \n  \nSo far this was found by code inspection, but let's just CC stable as the  \nfix is easy. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"11 Jan 2025\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2025-01-11T18:16:56.000000Z"}