Linux/Unix ホストには、ベンダーが提供するパッチが利用できない脆弱性の影響を受ける複数のパッケージがインストールされています。

  - HID:appletb-kbd:workqueue から非アクティブの autodim を実行します hid-appletb-kbd の autodim コードは、2 つの異なるアトミックコンテキストから backlight_device_set_brightness() -> mutex_lock() を介して backlight_device->ops_lock を取得します: * appletb_inactivity_timer() は構造体timer_listコールバックであるため、softirq コンテキストで実行されます。
    有効期限が経過するたびに BUG がトリガーされます:kernel/locking/mutex.c:591 で無効なコンテキストから呼び出されるスリープ関数 トレース呼び出し: <IRQ> __might_resched __mutex_lock backlight_device_set_brightness appletb_inactivity_timer call_timer_fn run_timer_softirq * reset_inactivity_timer() が appletb_kbd_hid_event() と appletb_kbd_inp_event() から呼び出されます。実際の USB ハードウェアでは、これらは softirq/IRQ コンテキスト(URB 完了および入力イベントディスパッチ)で実行されます。Touch Barがすでに淡色またはオフになっている場合、リセットパスはbacklight_device_set_brightness()を直接呼び出して明るさを復元し、同じ警告を発します。両方の呼び出しサイトが、同じ mutex_lock()-from-atomic バグに遭遇します。ブロッキング作業をシステム作業キューに移動することで、これらをまとめて修正します:* 非アクティブタイマーを構造体 timer_list から構造体 delayed_work に変換します。コールバック(appletb_inactivity_work)は、mutex_lock()が正当なプロセスコンテキストで実行されるようになりました。* 専用の構造体work_struct restore_brightness_workを追加し、backlight_device_set_brightness() を直接呼び出す代わりに、reset_inactivity_timer() にスケジュールさせます。Cancel は、既存のバックライト参照ドロップとともに、ドライバーのティアダウン中に両方を同期して動作します。セマンティックは変更されていません(同じ遅延、暗闇、オフ、およびユーザーアクティビティの同じ状態遷移)。スリープ中の呼び出しの実行コンテキストのみが変更されます。
    タイマー フィールドとコールバックの名前が、新しい型に合わせて変更されます。reset_inactivity_timer() は、非アクティブタイマーのリセットとして自然に読み取られる入力イベントパスから呼び出されるため、その名前を保持します。
    (CVE-2026-46202)

Nessus は、ベンダーによって報告されたパッケージの存在に依存していることに注意してください。

検出

Linux Distros のパッチ未適用の脆弱性: CVE-2026-46202

medium Nessus プラグイン ID 318492

バージョン 1.16