[SRU][J][PATCH 0/1] CVE-2024-57945
Cengiz Can
cengiz.can at canonical.com
Tue Sep 8 16:35:20 UTC 2026
https://ubuntu.com/security/CVE-2024-57945
[ Impact ]
In the Linux kernel, the following vulnerability has been resolved:
riscv: mm: Fix the out of bound issue of vmemmap address
In sparse vmemmap model, the virtual address of vmemmap is calculated as:
((struct page *)VMEMMAP_START - (phys_ram_base >> PAGE_SHIFT)). And the struct
page's va can be calculated with an offset: (vmemmap + (pfn)).
However, when initializing struct pages, kernel actually starts from the first
page from the same section that phys_ram_base belongs to. If the first page's
physical address is not (phys_ram_base >> PAGE_SHIFT), then we get an va below
VMEMMAP_START when calculating va for it's struct page.
For example, if phys_ram_base starts from 0x82000000 with pfn 0x82000, the
first page in the same section is actually pfn 0x80000. During
init_unavailable_range(), we will initialize struct page for pfn 0x80000 with
virtual address ((struct page *)VMEMMAP_START - 0x2000), which is below
VMEMMAP_START as well as PCI_IO_END.
This commit fixes this bug by introducing a new variable 'vmemmap_start_pfn'
which is aligned with memory section size and using it to calculate vmemmap
address instead of phys_ram_base.
[ Fix ]
jammy/linux: backported from f754f27e98f8
[ Test Plan ]
Build and boot tested.
[ Where Problems Could Occur ]
This change only touches RISC-V memory initialization, so any regression
would be confined to riscv systems using the sparse vmemmap model, in
particular those whose physical RAM base is not aligned to the memory
section size. A bad fix could miscompute the vmemmap base and corrupt or
mislocate struct page entries early in boot, potentially leading to a boot
failure or memory corruption on such platforms. Other architectures and
riscv systems whose RAM base is already section-aligned are not affected.
[ Other Info ]
Kybele flow-v11-21-g0f091652. Reference: 1543d686/v1
More information about the kernel-team
mailing list