CVE-2026-80682 in Linux
Summary
by MITRE • 08/28/2026
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.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 08/28/2026
The vulnerability identified involves a critical unit mismatch within the RISC-V memory management subsystem of the Linux kernel, specifically concerning the calculation of the virtual memory map start page frame number. The core issue stems from an incorrect assumption regarding alignment domains during system initialization. In the architecture-specific code for RISC-V, the variable vmemmap_start_pfn is computed by rounding down the physical RAM base address using a constant defined as VMEMMAP_ADDR_ALIGN. This operation requires that the alignment value be expressed in terms of physical addresses to correctly align memory structures within the physical address space. However, recent changes intended to optimize folio handling introduced MAX_FOLIO_VMEMMAP_ALIGN into this calculation. The fundamental flaw is that MAX_FOLIO_VMEMMAP_ALIGN represents an alignment requirement for struct page storage measured in bytes, whereas VMEMMAP_ADDR_ALIGN expects a value suitable for aligning physical addresses directly. This semantic error creates a discrepancy where the calculated base address does not satisfy the necessary hardware and software constraints required for proper memory management operations.
The operational impact of this vulnerability manifests primarily during early kernel initialization on systems with specific memory layouts, such as QEMU virtual machines using virtio configurations. The Linux kernel employs a mask-based compound_info encoding mechanism that mandates pfn_to_page(0) to be naturally aligned to MAX_FOLIO_VMEMMAP_ALIGN. When the system DRAM base is not perfectly aligned to multiples of MAX_FOLIO_NR_PAGES multiplied by PAGE_SIZE, the incorrect alignment calculation results in vmemmap_start_pfn failing this requirement. This failure triggers a warning condition within sparse_init, as indicated by kernel logs showing warnings related to memmap alignment checks for compound_info_has_mask(). While this may not always cause an immediate system crash on all hardware configurations due to varying memory layouts, it represents a significant stability risk and potential denial of service scenario where the kernel refuses to proceed with proper memory mapping or exhibits undefined behavior during page table management. The issue highlights how subtle unit mismatches in low-level memory initialization can lead to functional regressions that are difficult to diagnose without detailed knowledge of the underlying architecture constraints.
From a vulnerability classification perspective, this defect aligns with CWE-682 Incorrect Calculation and CWE-754 Improper Check for Unusual or Exceptional Conditions. The root cause is an incorrect calculation resulting from mixing different units of measurement (bytes versus physical page frame alignment) without proper conversion. In the context of the MITRE ATT&CK framework, this vulnerability relates to techniques involving resource manipulation during initialization phases, potentially allowing attackers who can influence boot parameters or memory layout in virtualized environments to trigger instability or denial of service conditions. The lack of robust validation for unit consistency allows such errors to persist until specific hardware configurations expose them, making it a latent defect that compromises system reliability and integrity.
To mitigate this vulnerability, the Linux kernel maintainers have implemented a fix that explicitly converts MAX_FOLIO_VMEMMAP_ALIGN from its byte-based representation into an equivalent physical alignment value before applying it within VMEMMAP_ADDR_ALIGN. This adjustment ensures that the round_down logic operates correctly on physical addresses while satisfying the mask-alignment requirements for compound_info structures. System administrators and developers should ensure they are running kernel versions where this patch is applied, particularly when deploying RISC-V based systems or virtual machines with non-standard memory alignments. Regular updates to the kernel base are essential to maintain compliance with these architectural constraints and prevent potential initialization failures that could disrupt service availability.