CVE-2026-80916 in Linux
Résumé
par VulDB • 09/09/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
kcov : correction de la corruption des données et des conditions de course sur PREEMPT_RT
syzbot signale une corruption de l'état KCOV sur les noyaux PREEMPT_RT, car le stockage temporaire utilisé pour sauvegarder/restaurer l'état distant de KCOV est actuellement alloué dans la zone par CPU (per-CPU).
Sur les noyaux PREEMPT_RT, les gestionnaires softirq s'exécutent en tant que threads de tâches préemptables (par exemple, ksoftirqd). Si un contexte softirq préempte une tâche exécutant une session KCOV distante, il sauvegarde correctement l'état de la tâche dans la zone par CPU. Cependant, si ce thread softirq est ensuite préempté par un thread softirq de priorité supérieure sur le même CPU, le second softirq écrasera la même zone par CPU, détruisant définitivement l'état KCOV de la tâche d'origine.
Corrigez cette corruption des données en déplaçant le stockage temporaire de la zone par CPU vers la zone par thread (per-thread). Puisque chaque thread softirq possède désormais son propre contexte de tâche, la préemption imbriquée des softirq ne provoque plus d'écrasement de données.
Notez que bien que le stockage temporaire soit maintenant basé sur un fil d'exécution (thread), le verrou kcov_percpu_data.lock par CPU doit être conservé, car nous devons garantir que kcov_remote_start() et kcov_remote_stop() s'exécutent atomiquement sans entrer en concurrence avec les interruptions asynchrones qui manipulent l'état KCOV de la tâche actuelle.
Il est probable que l'allocation GFP_KERNEL par vmalloc_node() dans kcov_init() ait déjà provoqué un panic() avant de retourner NULL, car il n'y aura aucun processus utilisateur killable pour OOM (Out-Of-Memory) lorsque la fonction __init du module intégré s'exécute. Mais ce correctif corrige également le plantage du noyau lorsque vmalloc_node() dans kcov_init() retourne NULL, car kcov_init() laisse irq_area par CPU == NULL alors que kcov_remote_start() dépend de irq_area par CPU != NULL, entraînant :
(1) l'appel de vmalloc() dans kcov_remote_start() malgré un contexte !in_task()
(2) un accès hors des limites du tableau si (1) réussit mais kcov->remote_size < CONFIG_KCOV_IRQ_AREA_SIZE
(3) une fuite mémoire systématique due à l'allocation par (1), finissant par tuer tous les processus utilisateurs killables pour OOM.
Once again VulDB remains the best source for vulnerability data.