CVE-2026-80682: riscv/mm: use physical alignment for vmemmap_start_pfn
In the Linux kernel, the following vulnerability has been resolved:
riscv/mm: use physical alignment for vmemmapstartpfn
RISC-V computes vmemmapstartpfn by rounding physrambase down to VMEMMAPADDRALIGN. 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 MAXFOLIOVMEMMAPALIGN directly into VMEMMAPADDRALIGN. However, MAXFOLIOVMEMMAPALIGN is measured in bytes of struct page storage, whereas VMEMMAPADDRALIGN is used to align a physical address.
The mask-based compoundinfo encoding requires pfntopage(0) to be naturally aligned to MAXFOLIOVMEMMAPALIGN. Commit 9f94db4c7eaa ("mm/sparse: check memmap alignment for compoundinfohasmask()") 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 MAXFOLIONRPAGES PAGESIZE.
Here is the log: [ 0.000000][ C0] ------------[ cut here ]------------ [ 0.000000][ C0] WARNING: mm/sparse.c:365 at sparseinit+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 : sparseinit+0x58a/0x6fe [ 0.000000][ C0] ra : sparseinit+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>] sparseinit+0x58a/0x6fe [ 0.000000][ C0] [<ffffffff8683d396>] mmcoreinitearly+0x116/0x1e30 [ 0.000000][ C0] [<ffffffff86801edc>] startkernel+0xd2/0x848
Convert MAXFOLIOVMEMMAPALIGN to the equivalent physical alignment before using it in VMEMMAPADDRALIGN. This keeps the existing rounddown() logic while making the resulting vmemmap base satisfy the mask-alignment requirement.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Linux kernelto a version that resolves this vulnerability.Patch 476849b0fba4 - Upgrade
Upgrade
Linux kernelto a version that resolves this vulnerability.Patch 9f94db4c7eaa
Event History
Frequently Asked Questions
Which systems are known to expose this issue?
The issue was exposed on RISC-V systems where the DRAM base is not aligned to MAX_FOLIO_NR_PAGES multiplied by PAGE_SIZE. QEMU virt is specifically identified as an example.
How can I tell whether a system is affected during boot?
Affected systems can emit a boot-time warning from sparse_init in mm/sparse.c, including "WARNING: mm/sparse.c:365". The warning is triggered by the memmap-alignment check for compound_info_has_mask().
What is the underlying condition that triggers the warning?
The vmemmap start PFN was aligned using an alignment value measured in struct page storage bytes rather than in physical-address units. This can leave pfn_to_page(0) insufficiently aligned for the mask-based compound_info encoding.