Linux/Unix 主機上安裝了一個或多個受到弱點影響的套件，且供應商未提供可用的修補程式。

  - Input： uinput - 修正具有 ff-core 的循環鎖定相依性 當使用帶有 uinput 的強制回饋遊戲手把時（例如，使用 Flydigi Vader 5 控制器在 Wine 下玩 ELDEN RING），可以重複觸發 lockdep 循環鎖定相依性警告：ff->mutex -> udev->mutex -> input_mutex -> dev->mutex
    -> ff->mutex 這個循環是由四個鎖定取得路徑引起的： 1. ff upload：input_ff_upload（） 持有 ff->mutex 並呼叫 uinput_dev_upload_effect（） -> uinput_request_submit（） -> uinput_request_send（），獲取 udev->mutex。2. 裝置建立：uinput_ioctl_handler（） 持有 udev->mutex 並呼叫 uinput_create_device（） -> input_register_device（），取得input_mutex。3. 設備暫存器：
    input_register_device（） 持有 input_mutex 並呼叫 kbd_connect（） -> input_register_handle（），這會取得 dev->mutex。4. evdev 發布：evdev_release（） 呼叫 dev->mutex 下的 input_flush_device（），後者呼叫 input_ff_flush（） 獲取 ff->mutex。透過引入新的 state_lock 微調鎖來保護 uinput_request_send（） 中的 udev->state 和 udev->dev 存取，而不是取得 udev->mutex，以解決此問題。此函式只需要以不可部分完成的方式檢查裝置狀態，並透過 uinput_dev_event（） 將輸入事件排入環形緩衝區 -- 這兩個作業在微調鎖定下都是安全的 （ktime_get_ts64（） 和 wake_up_interruptible（） 不休眠）。這會中斷 ff->mutex -> udev->mutex 連結，因為微調鎖是鎖定排序中的葉子，無法與互斥形成循環。若要讓狀態轉換對 uinput_request_send（） 可見，請使用相同的 state_lock 同步鎖定來保護 uinput_create_device（） 和 uinput_destroy_device（） 中對 udev->state 的寫入。此外，在 uinput_request_reserve_slot（） 之前將 init_completion（&request->done） 從 uinput_request_send（） 移至 uinput_request_submit（）。配置插槽後，uinput_flush_requests（） 可以隨時從銷毀路徑對其呼叫 complete（），因此必須在請求可見之前初始化完成。修正後的鎖定順序：ff->mutex
    -> state_lock （微調鎖，葉） udev->mutex -> state_lock （微調鎖，葉） udev->mutex -> input_mutex -> dev->mutex -> ff->mutex （無後緣） （CVE-2026-31667）

請注意，Nessus 的判定取決於廠商所報告的套件是否存在。

偵測

Linux Distros 未修補的弱點：CVE-2026-31667

high Nessus Plugin ID 310456

版本 1.24