Description

In the Linux kernel, the following vulnerability has been resolved: riscv/mm: use physical alignment for vmemmap_start_pfn RISC-V computes vmemmap_start_pfn by rounding phys_ram_base down to VMEMMAP_ADDR_ALIGN. That alignment must therefore be expressed in the physical-address domain. Commit 476849b0fba4 ("riscv/mm: align vmemmap to maximal folio size") attempted to account for the maximal folio alignment by feeding MAX_FOLIO_VMEMMAP_ALIGN directly into VMEMMAP_ADDR_ALIGN. However, MAX_FOLIO_VMEMMAP_ALIGN is measured in bytes of struct page storage, whereas VMEMMAP_ADDR_ALIGN is used to align a physical address. The mask-based compound_info encoding requires pfn_to_page(0) to be naturally aligned to MAX_FOLIO_VMEMMAP_ALIGN. Commit 9f94db4c7eaa ("mm/sparse: check memmap alignment for compound_info_has_mask()") added a check for that requirement and exposed the unit mismatch on systems such as QEMU virt, where the DRAM base is not aligned to MAX_FOLIO_NR_PAGES * PAGE_SIZE. Here is the log: [ 0.000000][ C0] ------------[ cut here ]------------ [ 0.000000][ C0] WARNING: mm/sparse.c:365 at sparse_init+0x58a/0x6fe, CPU#0: swapper/0 [ 0.000000][ C0] Modules linked in: [ 0.000000][ C0] CPU: 0 UID: 0 PID: 0 Comm: swapper Not tainted 7.2.0-rc3-g1d8304bdd65f #2 PREEMPT [ 0.000000][ C0] Hardware name: riscv-virtio,qemu (DT) [ 0.000000][ C0] epc : sparse_init+0x58a/0x6fe [ 0.000000][ C0] ra : sparse_init+0x58a/0x6fe [ 0.000000][ C0] epc : ffffffff86851c88 ra : ffffffff86851c88 sp : ffffffff88807a30 [ 0.000000][ C0] gp : ffffffff8a3bf240 tp : ffffffff88842080 t0 : ff600000ffab6000 [ 0.000000][ C0] t1 : 000000017fab6000 t2 : 65203a6573726363 s0 : ffffffff88807bc0 [ 0.000000][ C0] s1 : 000000000e000000 a0 : 0000000000000007 a1 : 0000000000000000 [ 0.000000][ C0] a2 : 0000000000000002 a3 : ffffffff86851c88 a4 : 0000000000000000 [ 0.000000][ C0] a5 : ffffffff88843080 a6 : 0000000000000003 a7 : 0000000000000000 [ 0.000000][ C0] s2 : ff60000000000000 s3 : 0040000000000000 s4 : 0004000000000000 [ 0.000000][ C0] s5 : ffffffff8a4d92e0 s6 : ff600000ffab55e0 s7 : ffffffff88384d00 [ 0.000000][ C0] s8 : 0000000000000003 s9 : ffffffff88384cc1 s10: ffffffff88384cc0 [ 0.000000][ C0] s11: ffffffff8a4daae0 t3 : ffffffff915e8b20 t4 : ffffffff915e8b20 [ 0.000000][ C0] t5 : ffffffff915e8b20 t6 : ffffffff915e8bc8 ssp : 0000000000000000 [ 0.000000][ C0] status: 0000000200000100 badaddr: ffffffff86851c88 cause: 0000000000000003 [ 0.000000][ C0] [<ffffffff86851c88>] sparse_init+0x58a/0x6fe [ 0.000000][ C0] [<ffffffff8683d396>] mm_core_init_early+0x116/0x1e30 [ 0.000000][ C0] [<ffffffff86801edc>] start_kernel+0xd2/0x848 Convert MAX_FOLIO_VMEMMAP_ALIGN to the equivalent physical alignment before using it in VMEMMAP_ADDR_ALIGN. This keeps the existing round_down() logic while making the resulting vmemmap base satisfy the mask-alignment requirement.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.8",
  "pubDate": "2026-08-28T08:16:53.607Z",
  "pubdate": "2026-08-28T08:16:53.607Z",
  "executiveSummary": "A memory management vulnerability exists in the Linux kernel for the RISC-V architecture due to an incorrect unit calculation for physical address alignment.\nThe flaw stems from a mismatch between byte-based alignment constants (MAX_FOLIO_VMEMMAP_ALIGN) and the physical-address domain expectations of the vmemmap allocation logic.\nThis vulnerability leads to a kernel WARNING during the sparse_init phase, as the physical-to-virtual memory mapping fails to meet alignment constraints required for compound_info encoding.\nWhile primarily a stability and kernel-integrity issue during early boot, failure to align memory structures can lead to memory corruption or undefined behavior when the system attempts to utilize large folio compound pages.\nThe issue affects systems where the DRAM base address is not aligned with the calculated MAX_FOLIO_NR_PAGES requirement, such as the QEMU virt platform.\nExploitation is not mentioned as a standard attack vector; however, the resulting instability effectively constitutes a denial-of-service (DoS) condition by crashing the boot process.",
  "technicalDetails": "The root cause of this vulnerability is a unit mismatch in the calculation of vmemmap_start_pfn on RISC-V Linux kernels. The kernel calculates vmemmap_start_pfn by rounding the physical RAM base down to a value defined by VMEMMAP_ADDR_ALIGN. However, the introduction of MAX_FOLIO_VMEMMAP_ALIGN—intended to support larger folio sizes—misapplied a byte-count constant to a physical-address alignment function.\nIn the memory management subsystem, sparse memory models utilize vmemmap to map struct page entries. The architecture requires that pfn_to_page(0) is naturally aligned to the requirements of MAX_FOLIO_VMEMMAP_ALIGN to support mask-based compound_info encoding. Commit 9f94db4c7eaa added a sanity check in mm/sparse.c:365, which triggers a kernel WARNING if this alignment is not satisfied during the sparse_init function.\nOn platforms like QEMU virt, the DRAM base address often fails to align with the product of MAX_FOLIO_NR_PAGES and PAGE_SIZE. Because the code was using a byte-oriented constant in the physical alignment logic, the resulting vmemmap_start_pfn was incorrectly calculated, causing the kernel to violate memory map alignment requirements.\nThe attack flow for this vulnerability occurs during the early boot sequence (start_kernel -> mm_core_init_early -> sparse_init). When the kernel initializes, it attempts to validate the alignment of the vmemmap. Upon encountering the misalignment, the kernel triggers a WARNING. Depending on kernel configuration (e.g., CONFIG_PANIC_ON_WARN), this boot-time check can halt the system, preventing successful kernel initialization.\nThe vulnerability is restricted to the kernel's memory management initialization process. While this does not represent a typical remote code execution (RCE) scenario, it is a critical architectural flaw. Improperly aligned vmemmap structures can lead to incorrect page metadata access, resulting in kernel panics or silent memory corruption when the kernel performs operations on compound pages. Because this occurs at the kernel level, it inherently requires local, privileged access to influence the boot environment or hardware-level configuration, though it manifests automatically upon boot in vulnerable hardware configurations."
}