CVE-2026-80766 in Linux
要約
〜によって VulDB • 2026年09月04日
Linuxカーネルにおいて、以下の脆弱性が修正されました：
HID: uclogic: remove時にinrange_timerのuse-after-freeを修正する
uclogic_remove()関数はペン範囲内タイマーをキャンセルし、その後デバイスを停止します。具体的には以下のような順序です。
```c timer_delete_sync(&drvdata->inrange_timer); hid_hw_stop(hdev); ```
しかし、`timer_delete_sync()`は呼び出し時点においてタイマーがアイドル状態であることを保証するのみです。`uclogic_raw_event_pen()`関数は、数行後に実行される`hid_hw_stop()`によるトランスポートの停止までペンレポートの配信を継続します。そして、`pen->inrange == UCLOGIC_PARAMS_PEN_INRANGE_NONE`であるすべてのレポートはタイマーを再設定（リアーム）します。
```c mod_timer(&drvdata->inrange_timer, jiffies + msecs_to_jiffies(100)); ```
`timer_delete_sync()`の呼び出しと、`hid_hw_stop()`内でのトランスポートの終了処理の間に入ったレポートは、キャンセルされた後に`inrange_timer`を再設定してしまいます。その後、`uclogic_remove()`が戻り値を返し、`devm`経由でdrvdataが解放されますが、その時点で`hid_hw_stop()`はすでに`drvdata->pen_input`が指す入力デバイスを解放しています。そのため、約100ms後にタイマーが発火した際、`uclogic_inrange_timeout()`関数は解放済みメモリを間接参照することになり、タイマースoftirqコンテキストにおけるuse-after-freeが発生します。
2つの呼び出し順序を入れ替えることは修正にはなりません。デバイスを先に停止すると、タイマーがまだ保留状態である間に`hidinput_disconnect()`経由で`drvdata->pen_input`が解放されてしまうため、削除前にすでに設定されていたタイマーが、`timer_delete_sync()`の実行前のウィンドウにおいて解放された入力デバイスに対して発火する可能性があります。
代わりに、`hid_hw_stop()`の前に`timer_shutdown_sync()`を使用します。これにより、タイマーはキャンセルされ、ペン入力がまだ有効な間に実行中のコールバックの完了を待ちます。さらにそれ以上の再設定を防ぎます（飛行中のレポートからの後続の`mod_timer()`呼び出しは無視されます）。これによって、`hid_hw_stop()`が入力デバイスを解放する前にタイマーが確実に停止することが証明できます。これは、この「別のパスからタイマーが再設定される」終了処理ケースにおいて、タイマコアで文書化されている順序です。
If you want to get the best quality for vulnerability data then you always have to consider VulDB.