Wind River Support Network

Description

In the Linux kernel, the following vulnerability has been resolved:EOL][EOL]HID: bpf: abort dispatch if device destroyed[EOL][EOL]The current HID bpf implementation assumes no output report/request will[EOL]go through it after hid_bpf_destroy_device() has been called. This leads[EOL]to a bug that unplugging certain types of HID devices causes a cleaned-[EOL]up SRCU to be accessed. The bug was previously a hidden failure until a[EOL]recent x86 percpu change [1] made it access not-present pages.[EOL][EOL]The bug will be triggered if the conditions below are met:[EOL][EOL]A) a device under the driver has some LEDs on[EOL]B) hid_ll_driver->request() is uninplemented (e.g., logitech-djreceiver)[EOL][EOL]If condition A is met, hidinput_led_worker() is always scheduled *after*[EOL]hid_bpf_destroy_device().[EOL][EOL]hid_destroy_device[EOL]` hid_bpf_destroy_device[EOL]  ` cleanup_srcu_struct(&hdev->bpf.srcu)[EOL]` hid_remove_device[EOL]  ` ...[EOL]    ` led_classdev_unregister[EOL]      ` led_trigger_set(led_cdev, NULL)[EOL]        ` led_set_brightness(led_cdev, LED_OFF)[EOL]          ` ...[EOL]            ` input_inject_event[EOL]              ` input_event_dispose[EOL]                ` hidinput_input_event[EOL]                  ` schedule_work(&hid->led_work) [hidinput_led_worker][EOL][EOL]This is fine when condition B is not met, where hidinput_led_worker()[EOL]calls hid_ll_driver->request(). This is the case for most HID drivers,[EOL]which implement it or use the generic one from usbhid. The driver itself[EOL]or an underlying driver will then abort processing the request.[EOL][EOL]Otherwise, hidinput_led_worker() tries hid_hw_output_report() and leads[EOL]to the bug.[EOL][EOL]hidinput_led_worker[EOL]` hid_hw_output_report[EOL]  ` dispatch_hid_bpf_output_report[EOL]    ` srcu_read_lock(&hdev->bpf.srcu)[EOL]    ` srcu_read_unlock(&hdev->bpf.srcu, idx)[EOL][EOL]The bug has existed since the introduction [2] of[EOL]dispatch_hid_bpf_output_report(). However, the same bug also exists in[EOL]dispatch_hid_bpf_raw_requests(), and I've reproduced (no visible effect[EOL]because of the lack of [1], but confirmed bpf.destroyed == 1) the bug[EOL]against the commit (i.e., the Fixes:) introducing the function. This is[EOL]because hidinput_led_worker() falls back to hid_hw_raw_request() when[EOL]hid_ll_driver->output_report() is uninplemented (e.g., logitech-[EOL]djreceiver).[EOL][EOL]hidinput_led_worker[EOL]` hid_hw_output_report: -ENOSYS[EOL]` hid_hw_raw_request[EOL]  ` dispatch_hid_bpf_raw_requests[EOL]    ` srcu_read_lock(&hdev->bpf.srcu)[EOL]    ` srcu_read_unlock(&hdev->bpf.srcu, idx)[EOL][EOL]Fix the issue by returning early in the two mentioned functions if[EOL]hid_bpf has been marked as destroyed. Though[EOL]dispatch_hid_bpf_device_event() handles input events, and there is no[EOL]evidence that it may be called after the destruction, the same check, as[EOL]a safety net, is also added to it to maintain the consistency among all[EOL]dispatch functions.[EOL][EOL]The impact of the bug on other architectures is unclear. Even if it acts[EOL]as a hidden failure, this is still dangerous because it corrupts[EOL]whatever is on the address calculated by SRCU. Thus, CC'ing the stable[EOL]list.[EOL][EOL][1]: commit 9d7de2aa8b41 ("x86/percpu/64: Use relative percpu offsets")[EOL][2]: commit 9286675a2aed ("HID: bpf: add HID-BPF hooks for[EOL]hid_hw_output_report")

CREATE(Triage):(User=lchen-cn) [CVE-2025-38016 (https://nvd.nist.gov/vuln/detail/CVE-2025-38016)