{"uuid": "ea688d21-5f77-42eb-81b5-b52aca816278", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2024-57945", "type": "seen", "source": "https://t.me/cvedetector/15937", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-57945 - \"Riscv Linux Kernel Out-of-Bounds Memory Access Vulnerability\"\", \n  \"Content\": \"CVE ID : CVE-2024-57945 \nPublished : Jan. 21, 2025, 1:15 p.m. | 42\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nriscv: mm: Fix the out of bound issue of vmemmap address  \n  \nIn sparse vmemmap model, the virtual address of vmemmap is calculated as:  \n((struct page *)VMEMMAP_START - (phys_ram_base >> PAGE_SHIFT)).  \nAnd the struct page's va can be calculated with an offset:  \n(vmemmap + (pfn)).  \n  \nHowever, when initializing struct pages, kernel actually starts from the  \nfirst page from the same section that phys_ram_base belongs to. If the  \nfirst page's physical address is not (phys_ram_base >> PAGE_SHIFT), then  \nwe get an va below VMEMMAP_START when calculating va for it's struct page.  \n  \nFor example, if phys_ram_base starts from 0x82000000 with pfn 0x82000, the  \nfirst page in the same section is actually pfn 0x80000. During  \ninit_unavailable_range(), we will initialize struct page for pfn 0x80000  \nwith virtual address ((struct page *)VMEMMAP_START - 0x2000), which is  \nbelow VMEMMAP_START as well as PCI_IO_END.  \n  \nThis commit fixes this bug by introducing a new variable  \n'vmemmap_start_pfn' which is aligned with memory section size and using  \nit to calculate vmemmap address instead of phys_ram_base. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"21 Jan 2025\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2025-01-21T15:17:16.000000Z"}