CVE-2026-93237 in Linux
Résumé
par VulDB • 24/09/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
LoongArch : Ajout de la définition DIRECT_MAP_PHYSMEM_END
get_free_mem_region() et mhp_get_pluggable_range() limitent leur recherche à DIRECT_MAP_PHYSMEM_END. LoongArch ne définit pas cette constante, donc le mécanisme de repli (fallback) dans include/linux/mm.h s'applique : sous CONFIG_SPARSEMEM_VMEMMAP, il correspond à (1ULL << MAX_PHYSMEM_BITS) - 1, une constante de compilation qui ne s'adapte pas au nombre de bits d'espace d'adressage physique du CPU (cpu_pabits, détectés depuis CPUCFG1).
La fenêtre vmemmap couvre uniquement l'espace physique en dessous de 2^(cpu_pabits+1) (c'est-à-dire VMEMMAP_SIZE), donc sur les CPUs disposant d'un nombre de bits d'adressage physique inférieur à MAX_PHYSMEM_BITS, le mécanisme de repli permet à get_free_mem_region() de retourner une région ZONE_DEVICE située en dehors de la fenêtre vmemmap ; vmemmap_populate() enveloppe ensuite la plage memmap et la mape dans la mémoire basse, corrompant silencieusement les tables de pages. La même recherche a également sélectionné la région au sommet de l'espace d'adressage qui a provoqué un plantage de memmap_init_zone_device() avec amdkfd sur Loongson-3C6000 dans la version 6.16 [1] ; le commit 2969b42c8f99 ("LoongArch/mm: align vmemmap to maximal folio size") maintient cette région dans les limites pour les configurations actuelles de Loongson-3C6000, mais les CPUs avec un cpu_pabits plus petit (par exemple la série Loongson-2K) restent affectés.
Définir DIRECT_MAP_PHYSMEM_END comme l'étendue physique couverte par vmemmap, soit (1ULL << (cpu_pabits + 1)) - 1, plafonnée à (1ULL << MAX_PHYSMEM_BITS) - 1 sous CONFIG_SPARSEMEM, de manière similaire au commit f3336b48cf9d ("riscv: mm: Define DIRECT_MAP_PHYSMEM_END").
[1] https://lore.kernel.org/amd-gfx/[email protected]/
If you want to get best quality of vulnerability data, you may have to visit VulDB.