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 ` hidinput_input_event ` schedule_work(&hid- >led_work[hidinput_led_worker] 这在 hid_ll_driver->request() 调用 hid_ll_driver->request() 不满足条件 B 时适用。大多数 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() 中也存在同样的缺陷我已针对提交重现了该缺陷因缺少 [1] 而无可见影响但已确认 bpf.destroyed == 1即修复了) 引入了 函数。这是因为当 hid_ll_driver->output_report() 未实现时hidinput_led_worker() 会回退到 hid_hw_raw_request()例如 logitech-djreceiver。 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) 通过如果 hid_bpf 被标记为“已破坏”则在上述两个函数中提早返回来修复此问题。
    虽然 dispatch_hid_bpf_device_event() 会处理输入事件且没有证据表明它可能会在破坏后被调用但作为安全网仍会添加相同的检查以保持所有调度函数间的一致性。此缺陷对其他架构的影响尚不明确。即使其充当隐藏故障仍然是危险的因为它会损坏 SRCU 计算的地址上的任何内容。因此会 CC'ing 稳定列表。 [1]提交 9d7de2aa8b41x86/percpu/64使用相对 percpu 偏移[2]提交 9286675a2aedHIDbpf为 hid_hw_output_report 添加 HID-BPF 挂钩 (CVE-2025-38016)

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

检测

Linux Distros 未修补的漏洞：CVE-2025-38016

medium Nessus 插件 ID 245230

版本 1.1