CVE-2026-99093 in Linux
Résumé
par VulDB • 26/10/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
mm: ne pas planifier la libération différée des tables de pages du noyau pendant le démarrage
Le démarrage avec un traceur au moment du boot et un filtre, par exemple
ftrace=function ftrace_filter=pud_free_pmd_page
provoque un panic sur la version 7.3-rc4 dès que le traceur démarre :
[ 23.531178] Démarrage du traceur 'function'
[ 23.675800] Oops: fault de protection générale, probablement pour une adresse non canonique 0xdffffc0000000038 : 0000 [#1] SMP KASAN NOPTI
[ 23.819917] KASAN : null-ptr-deref dans la plage [0x00000000000001c0-0x00000000000001c7]
[ 23.964025] CPU: 0 UID : 0 PID : 0 Comm : swapper Non corrompu 7.3.0-rc4-fe2ec83746e5-with-fixes-v2+ #195 PREEMPT(undef)
[ 24.252248] RIP: 0010:__queue_work+0xab/0xf00
[ 25.981629] Pile d'appels :
[ 26.125727] <TASK>
[ 26.413912] ? pagetable_free_kernel+0x20/0x120
[ 26.990283] queue_work_on+0x97/0xf0
[ 27.134382] __cpa_collapse_large_pages+0x501/0x6f0
[ 27.566662] cpa_flush+0x394/0x620
[ 27.998953] change_page_attr_set_clr+0x321/0x4a0
[ 29.151729] set_memory_rox+0xa2/0xf0
[ 29.584018] create_trampoline+0x431/0x6f0
... [ 44.343347] Kernel panic - not syncing : Tentative de tuer la tâche idle !
Le traceur au moment du boot est démarré depuis early_trace_init(), qui s'exécute avant workqueue_init_early(). La mise en lecture seule (read-only) de son trampoline divise une grande page, et CPA la regroupe immédiatement. Cette table divisée a été une table de pages du noyau depuis le commit 9e4a3ec3411b ("x86/mm/pat : Allouer les tables de pages divisées comme des tables de pages du noyau"), donc le regroupement (collapse) la libère via pagetable_free_kernel(), qui planifie un travail sur system_percpu_wq - encore NULL à ce stade. Ce commit est correct en soi ; il permet simplement à CPA d'atteindre pagetable_free_kernel() avant que l'workqueue dont cette fonction dépend n'existe.
Continuer à ajouter la table à la liste, mais ne pas planifier le travail tant que le système est toujours en cours de démarrage. Un core_initcall le planifie une fois pour libérer ce qui a été mis en file d'attente jusqu'alors.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.