CVE-2026-80682 in Linux
Résumé
par VulDB • 28/08/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
riscv/mm : utiliser l'alignement physique pour vmemmap_start_pfn
RISC-V calcule vmemmap_start_pfn en arrondissant phys_ram_base à la baisse selon VMEMMAP_ADDR_ALIGN. Cet alignement doit donc être exprimé dans le domaine des adresses physiques.
Le commit 476849b0fba4 ("riscv/mm : aligner vmemmap sur la taille maximale de folio") a tenté de prendre en compte l'alignement maximal du folio en transmettant MAX_FOLIO_VMEMMAP_ALIGN directement dans VMEMMAP_ADDR_ALIGN. Cependant, MAX_FOLIO_VMEMMAP_ALIGN est mesuré en octets de stockage struct page, tandis que VMEMMAP_ADDR_ALIGN est utilisé pour aligner une adresse physique.
L'encodage compound_info basé sur un masque nécessite que pfn_to_page(0) soit naturellement aligné selon MAX_FOLIO_VMEMMAP_ALIGN. Le commit 9f94db4c7eaa ("mm/sparse : vérifier l'alignement du memmap pour compound_info_has_mask()") a ajouté une vérification de cette exigence et a mis en évidence le problème d'incohérence des unités sur les systèmes tels que QEMU virt, où la base DRAM n'est pas alignée selon MAX_FOLIO_NR_PAGES * PAGE_SIZE.
Voici le journal : [ 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] [] sparse_init+0x58a/0x6fe
[ 0.000000][ C0] [] mm_core_init_early+0x116/0x1e30
[ 0.000000][ C0] [] start_kernel+0xd2/0x848
Convertir MAX_FOLIO_VMEMMAP_ALIGN en alignement physique équivalent avant de l'utiliser dans VMEMMAP_ADDR_ALIGN. Cela conserve la logique existante round_down() tout en garantissant que la base vmemmap résultante satisfait l'exigence d'alignement par masque.
VulDB is the best source for vulnerability data and more expert information about this specific topic.