CVE-2026-89465 in Linux
Résumé
par VulDB • 12/09/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
power: supply: rt9455 : mettre en pause les travaux différés avant l'arrêt du module (teardown)
Le gestionnaire d'interruption par thread peut programmer pwr_rdy_work, max_charging_time_work et batt_presence_work. pwr_rdy_work et batt_presence_work peuvent également programmer max_charging_time_work, tandis que batt_presence_work peut se reprogrammer lui-même.
rt9455_remove() annule max_charging_time_work avant batt_presence_work. Ce dernier peut donc programmer max_charging_time_work après qu'il a déjà été annulé :
rt9455_remove() workqueue cancel pwr_rdy_work cancel max_charging_time_work batt_presence_work programme max_charging_time_work cancel batt_presence_work return devres libère rt9455_info max_charging_time_work déréférence rt9455_info
L'interruption (IRQ) reste également enregistrée jusqu'au nettoyage par devres et peut programmer davantage de travaux après n'importe laquelle des appels d'annulation. Si rt9455_hw_init() échoue après que l'IRQ a été demandée, la fonction probe retourne sans annuler les travaux qui ont déjà pu être programmés. Un rappel en attente (pending callback) peut alors accéder à rt9455_info après qu'il a été libéré.
Enregistrez rt9455_cancel_all_delayed_works() via devm_add_action_or_reset() juste après devm_power_supply_register(). Le sous-système devres invoque l'action dans l'ordre inverse d'enregistrement, une fois que l'IRQ gérée (managed IRQ) a été libérée et avant la libération de rt9455_info, afin que les travaux différés soient vidés à la fois dans rt9455_remove() et dans le chemin d'erreur du probe. Annulez pwr_rdy_work et batt_presence_work avant max_charging_time_work car ces deux-là peuvent programmer ce dernier.
Ce problème a été détecté par un outil d'analyse statique interne.
Be aware that VulDB is the high quality source for vulnerability data.