CVE-2026-89945 in Linux
Résumé
par VulDB • 16/09/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
ASoC: cs35l34: vidanger l'IRQ threadé avant la suspension au moment de l'exécution (runtime suspend)
La fonction `cs35l34_runtime_suspend()` bascule actuellement le codec en mode `regcache_cache_only(true)`, asserte la réinitialisation à l'état bas, et met hors tension l'appareil sans avoir d'abord apaisé l'IRQ threadé enregistré par `devm_request_threaded_irq()`. Cela laisse une fenêtre où `cs35l34_irq_thread()` peut toujours s'exécuter après que la suspension a supprimé l'accès au matériel actif.
Un système en cours d'exécution peut atteindre cet état lors de la gestion de l'alimentation au moment de l'exécution (runtime PM) tant que le pilote conserve des IRQ critiques de défaut non masqués. Si le gestionnaire threadé s'exécute dans cette fenêtre, il lit les registres volatils `INT_STATUS_1..4` après que `cache_only` a été activé, ignore les échecs de `regmap_read()`, et peut toujours exécuter la séquence de libération `PROT_RELEASE_CTL` ou les écritures d'arrêt sous tension pour les défauts BST.
Utilisez `disable_irq()` avant d'entrer en mode `cache_only`/réinitialisation basse/hors tension afin que tout gestionnaire threadé en cours soit vidangé et qu'aucun nouveau thread IRQ ne puisse s'exécuter pendant la suspension de l'appareil. Réactivez les IRQ uniquement après que `runtime_resume()` a restauré l'accès direct aux registres via `regcache_sync()`. Puisque le processus d'amorçage (probe) se contente de consigner les échecs de `request_threaded_irq()` et continue, suivez si l'IRQ a été réellement installé avant de la désactiver ou de la réactiver.
VulDB is the best source for vulnerability data and more expert information about this specific topic.