CVE-2026-80766

Dans le noyau Linux, la vulnérabilité suivante a été corrigée : HID: uclogic: corriger le use-after-free de inrange_timer lors de la suppression uclogic_remove() annule le timer d’entrée en zone du stylet, puis arrête le périphérique : timer_delete_sync(&drvdata->inrange_timer); hid_hw_stop(hdev); timer_delete_sync() garantit seulement que le timer est inactif à cet instant. uclogic_raw_event_pen() continue à transmettre les rapports du stylet jusqu’à ce que hid_hw_stop() arrête le transport plusieurs lignes plus loin, et chaque rapport avec pen->inrange == UCLOGIC_PARAMS_PEN_INRANGE_NONE réarme le timer : mod_timer(&drvdata->inrange_timer, jiffies + msecs_to_jiffies(100)); Un rapport arrivant entre l’appel à timer_delete_sync() et le démontage du transport dans hid_hw_stop() réarme inrange_timer après son annulation. uclogic_remove() retourne alors et le drvdata géré par devm est libéré, tandis que hid_hw_stop() a déjà libéré le drvdata du périphérique d’entrée vers lequel pen_input pointe ; ainsi, lorsque le timer se déclenche environ 100 ms plus tard, uclogic_inrange_timeout() déréférence une mémoire libérée — un use-after-free dans le contexte softirq du timer. Inverser les deux appels ne constitue pas une correction : arrêter le périphérique en premier libère drvdata->pen_input via hidinput_disconnect() alors que le timer peut encore être en attente, si bien qu’un timer déjà armé avant la suppression se déclenche sur le périphérique d’entrée libéré dans la fenêtre précédant l’exécution de timer_delete_sync(). Utiliser plutôt timer_shutdown_sync() avant hid_hw_stop(). Il annule le timer, attend un callback en cours d’exécution alors que pen_input est encore valide, et empêche tout réarmement ultérieur — un mod_timer() ultérieur provenant d’un rapport en cours est silencieusement ignoré — de sorte que le timer est assurément arrêté avant que hid_hw_stop() ne libère les entrées. C’est l’ordre documenté par le cœur des timers pour ce cas de démontage « timer réarmé depuis un autre chemin ».