cbcvebase.
CVE-2025-38016
published 2025-06-18

CVE-2025-38016: In the Linux kernel, the following vulnerability has been resolved: HID: bpf: abort dispatch if device destroyed The current HID bpf implementation assumes no…

PriorityP423medium5.5CVSS 3.1
AVLACLPRLUINSUCNINAH
EPSS
0.16%
5.7th percentile
In the Linux kernel, the following vulnerability has been resolved: HID: bpf: abort dispatch if device destroyed The current HID bpf implementation assumes no output report/request will go through it after hid_bpf_destroy_device() has been called. This leads to a bug that unplugging certain types of HID devices causes a cleaned- up SRCU to be accessed. The bug was previously a hidden failure until a recent x86 percpu change [1] made it access not-present pages. The bug will be triggered if the conditions below are met: A) a device under the driver has some LEDs on B) hid_ll_driver->request() is uninplemented (e.g., logitech-djreceiver) If condition A is met, hidinput_led_worker() is always scheduled *after* 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] This is fine when condition B is not met, where hidinput_led_worker() calls hid_ll_driver->request(). This is the case for most HID drivers, which implement it or use the generic one from usbhid. The driver itself or an underlying driver will then abort processing the request. Otherwise, hidinput_led_worker() tries hid_hw_output_report() and leads to the bug. 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) The bug has existed since the introduction [2] of dispatch_hid_bpf_output_report(). However, the same bug also exists in dispatch_hid_bpf_raw_requests(), and I've reproduced (no visible effect because of the lack of [1], but confirmed bpf.destroyed == 1) the bug against the commit (i.e., the Fixes:) introducing the function. This is because hidinput_led_worker() falls back to hid_hw_raw_request()

Affected

10 ranges
VendorProductVersion rangeFixed in
debianlinux< linux 6.12.30-1 (forky)linux 6.12.30-1 (forky)
linuxlinux
linuxlinux>= 8bd0488b5ea58655ad6fdcbe0408ef49b16882b1 < f8544be7e8e55b0ef23e1ab90e23e8d4d4aad3d3f8544be7e8e55b0ef23e1ab90e23e8d4d4aad3d3
linuxlinux>= 8bd0488b5ea58655ad6fdcbe0408ef49b16882b1 < e4b4fe25a4101d1ddb5884f40e149a3618983b66e4b4fe25a4101d1ddb5884f40e149a3618983b66
linuxlinux>= 8bd0488b5ea58655ad6fdcbe0408ef49b16882b1 < 578e1b96fad7402ff7e9c7648c8f1ad0225147c8578e1b96fad7402ff7e9c7648c8f1ad0225147c8
linuxlinux_kernel
linuxlinux_kernel>= 0 < 6.12.30-16.12.30-1
linuxlinux_kernel>= 0 < 6.12.30-16.12.30-1
linuxlinux_kernel>= 6.11 < 6.12.306.12.30
linuxlinux_kernel>= 6.13 < 6.14.86.14.8

CVSS provenance

nvdv3.15.5MEDIUMCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
osv7.8HIGH
vendor_ubuntu7.8HIGH
vendor_debian5.5LOW
vendor_redhat5.5MEDIUM
Stop checking back — get the weekly exploitation signal.

Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.