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

  - HIDbpf如果裝置已損毀則中止分派。目前的 HID bpf 實作假設在呼叫 hid_bpf_destroy_device() 之後沒有輸出報告/要求會經過它。這會導致產生一個錯誤拔除特定類型的 HID 裝置時會造成清理的 SRCU 遭到存取。此錯誤之前為隱藏失敗直到最近的 x86 percpu 變更 [1] 使其可存取不存在的頁面。若符合下列條件則將觸發此錯誤A) 驅動程式底下的裝置有部分 LED B) 未實作 hid_ll_driver->request() (例如 logitech-djreceiver) 如果符合條件 A則 hidinput_led_worker()一律在 hid_bpf_destroy_device() 之後* 排程。 hid_destroy_device ` hid_bpf_destroy_device ` cleanup_srcu_struct(&hdev->bpf.srcu) ` hid_remove_device ` ... ` led_classdev_unregister ` led_trigger_set(led_cdev, NULL) ` led_set_brightness(led_cdev, LED_OFF) `input_inject_event ` input_event_dispose ( &hhid_input_dispose `hidhid_input_unregister `led_trigger_set(led_cdev, NULL) `led_set_brightness(led_cdev, LED_OFF) ` >led_work) [hidinput_led_worker] 不符合條件 B (hidinput_led_worker() 呼叫 hid_ll_driver->request() 時) 情況良好。大多數 HID 驅動程式都是如此，這些驅動程式會實作或使用 usbhid 的通用驅動程式。驅動程式本身或基礎驅動程式隨後會中止處理要求。否則hidinput_led_worker() 會嘗試 hid_hw_output_report() 並導致錯誤。 hidinput_led_worker ` hid_hw_output_report ` dispatch_hid_bpf_output_report ` srcu_read_lock(&hdev->bpf.srcu) ` srcu_read_unlock(&hdev->bpf.srcu, idx) 此錯誤自 dispatch_hid_bpf_output_report() 引入 [2] 即存在。不過dispatch_hid_bpf_raw_requests() 中也有相同的錯誤而且我已針對認可重現 (即修正) 引入函式。這是因為未實作 hid_ll_driver->output_report() (例如logitech-djreceiver) 時hidinput_led_worker() 會回復至 hid_hw_raw_request()。 hidinput_led_worker ` hid_hw_output_report: -ENOSYS ` hid_hw_raw_request ` dispatch_hid_bpf_raw_requests ` srcu_read_lock(&hdev->bpf.srcu) ` srcu_read_unlock(&hdev->bpf.srcu, idx) 修正問題。
    雖然 dispatch_hid_bpf_device_event() 會處理輸入事件且並無證據顯示其可在解構後遭到呼叫但係統仍會新增相同的檢查 (作為安全網)以維持所有分派函式之間的一致性。不清楚該錯誤對其他架構的影響。即使它作為隱藏失敗運作這仍然很危險因為它會損毀 SRCU 計算的位址上的任何內容。因此CC'ing 穩定清單。 [1]提交 9d7de2aa8b41 (x86/percpu/64使用 percpu 相對位移) [2]提交 9286675a2aed (HIDbpf新增 hid_hw_output_report 的 HID-BPF 勾點) (CVE-2025-38016)

請注意，Nessus 依賴供應商報告的套件存在。

偵測

Linux Distros 未修補的弱點：CVE-2025-38016

medium Nessus Plugin ID 245230

版本 1.17