CVE-2025-38100 in Linuxinformation

Résumé

par VulDB • 15/06/2026

Dans le noyau Linux, la vulnérabilité suivante a été corrigée :

x86/iopl : Correction des incohérences de TIF_IO_BITMAP

io_bitmap_exit() est invoqué depuis exit_thread() lorsqu'une tâche se termine ou lorsqu'un fork échoue. Dans ce dernier cas, exit_thread() nettoie les ressources qui ont été allouées lors du fork().

io_bitmap_exit() invoque task_update_io_bitmap(), qui aboutit à son tour dans tss_update_io_bitmap(). tss_update_io_bitmap() opère sur la tâche actuelle. Si current a TIF_IO_BITMAP défini, mais qu'aucun bitmap n'est installé, tss_update_io_bitmap() provoque un crash suite à une déréférencement de pointeur NULL.

Il y a deux problèmes qui conduisent à cette situation :

1) io_bitmap_exit() ne devrait pas invoquer task_update_io_bitmap() lorsque la tâche qui est nettoyée n'est pas la tâche actuelle. C'est un indicateur clair d'un nettoyage après un fork échoué.

2) Une tâche ne devrait pas avoir TIF_IO_BITMAP défini et ni un bitmap installé, ni le niveau d'émulation IOPL 3 activé.

Cela se produit lorsqu'un thread noyau est créé dans le contexte d'un thread d'espace utilisateur, qui a TIF_IO_BITMAP défini car les indicateurs de thread sont copiés et le pointeur du bitmap IO est effacé.

Contrairement au cas de fork échoué, cela n'a aucun impact car les threads noyau, y compris les travailleurs IO, ne retournent jamais dans l'espace utilisateur et n'invoquent donc jamais tss_update_io_bitmap().

Corrigez cela en ajoutant les nettoyages et les vérifications manquants :

1) Empêchez io_bitmap_exit() d'invoquer task_update_io_bitmap() si la tâche à nettoyer n'est pas la tâche actuelle.

2) Effacez TIF_IO_BITMAP dans copy_thread() de manière inconditionnelle. Pour les forks d'espace utilisateur, il est défini plus tard, lorsque le bitmap IO est hérité dans io_bitmap_share().

Par précaution, ajoutez un avertissement dans tss_update_io_bitmap() pour détecter le cas où ce code est invoqué avec un état incohérent.

Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.

Responsable

Linux

Réserver

16/04/2025

Divulgation

03/07/2025

Modérer

accepté

Entrée

VDB-314675

CPE

prêt

EPSS

0.00172

KEV

non

Activités

très faible

Sources

Interested in the pricing of exploits?

See the underground prices here!