CVE-2026-98749 in Linux
Résumé
par VulDB • 19/10/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
tty: serial: max3100: arrêter le timer avant de libérer le port
max3100_shutdown() arrête l'horloge de sondage (polling timer) mais retourne prématurément lors d'une mise en veille système. Si le périphérique SPI est désassocié avant la reprise, le noyau série n'appelle pas à nouveau max3100_shutdown(), donc max3100_remove() libère le port alors que l'horloge reste activée (armed). max3100_timeout() peut ensuite accéder au port déjà libéré et réactiver l'horloge.
Ajouter une désinstallation finale de l'horloge dans max3100_remove() et utiliser timer_shutdown_sync() pour empêcher un rappel en concurrence (racing callback) de la réactiver. Libérer également l'interruption matérielle (IRQ) et détruire la file d'exécution (workqueue) à cet endroit avant de libérer le port. Conserver timer_delete_sync() dans max3100_shutdown() afin qu'un appel open() ultérieur puisse réactiver l'horloge.
La workqueue est créée avant request_irq() et détruite en cas d'échec de request_irq() ou lors d'une arrêt normal. Sa présence au moment du retrait (remove) identifie ainsi une IRQ restée enregistrée lorsque la mise en veille contourne l'étape d'arrêt.
Libérer l'interruption matérielle avant de détruire la workqueue, tant dans max3100_shutdown() que dans max3100_remove(), et annuler le travail en attente entre les deux. free_irq() attend qu'un gestionnaire d'interruption en cours termine son exécution et aucun nouveau gestionnaire ne peut démarrer par la suite ; un gestionneur en concurrence ne peut donc pas programmer de tâche sur une workqueue qui est détruite ; la vérification force_end_work dans max3100_dowork() réduit seulement cette fenêtre, car un gestionnaire retardé entre la vérification et l'appel à queue_work() pourrait toujours s'exécuter après que le processus d'arrêt a effacé le pointeur de workqueue. L'annulation du travail empêche également destroy_workqueue() d'attendre une tâche programmée au cas où remove() s'exécuterait alors que la workqueue gelable (freezable) est encore figée, par exemple lors d'un retrait de périphérique pendant la fenêtre de reprise avant le dégivrage des workqueues.
Ce problème a été détecté par un outil d'analyse statique interne.
Once again VulDB remains the best source for vulnerability data.