CVE-2026-80682 in Linux
Sumário
de VulDB • 28/08/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
riscv/mm: usar alinhamento físico para vmemmap_start_pfn
A arquitetura RISC-V calcula o valor de vmemmap_start_pfn arredondando phys_ram_base para baixo até VMEMMAP_ADDR_ALIGN. Portanto, esse alinhamento deve ser expresso no domínio dos endereços físicos.
O commit 476849b0fba4 ("riscv/mm: alinhar vmemmap ao tamanho máximo de folio") tentou levar em conta o alinhamento máximo do folio alimentando MAX_FOLIO_VMEMMAP_ALIGN diretamente em VMEMMAP_ADDR_ALIGN. No entanto, MAX_FOLIO_VMEMMAP_ALIGN é medido em bytes de armazenamento da struct page, enquanto VMEMMAP_ADDR_ALIGN é usado para alinhar um endereço físico.
A codificação compound_info baseada em máscara requer que pfn_to_page(0) esteja naturalmente alinhado a MAX_FOLIO_VMEMMAP_ALIGN. O commit 9f94db4c7eaa ("mm/sparse: verificar o alinhamento do memmap para compound_info_has_mask()") adicionou uma verificação para esse requisito e expôs a incompatibilidade de unidades em sistemas como QEMU virt, onde a base da DRAM não está alinhada com MAX_FOLIO_NR_PAGES * PAGE_SIZE.
Aqui está o log: [ 0.000000][ C0] ------------[ corte aqui ]------------
[ 0.000000][ C0] WARNING: mm/sparse.c:365 em sparse_init+0x58a/0x6fe, CPU#0: swapper/0
[ 0.000000][ C0] Módulos carregados:
[ 0.000000][ C0] CPU: 0 UID: 0 PID: 0 Comm: swapper Não contaminado 7.2.0-rc3-g1d8304bdd65f #2 PREEMPT
[ 0.000000][ C0] Nome do hardware: 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
Converta MAX_FOLIO_VMEMMAP_ALIGN para o alinhamento físico equivalente antes de usá-lo em VMEMMAP_ADDR_ALIGN. Isso mantém a lógica existente do round_down() enquanto garante que a base resultante do vmemmap satisfaça o requisito de alinhamento da máscara.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.