Linux Kernel up to 6.12.29/6.14.7 HID hid_bpf_destroy_device injection

Summaryinfo

A vulnerability was found in Linux Kernel up to 6.12.29/6.14.7. It has been declared as problematic. Affected is the function hid_bpf_destroy_device of the component HID. Executing a manipulation can lead to injection. This vulnerability is registered as CVE-2025-38016. No exploit is available. It is recommended to upgrade the affected component.

Detailsinfo

A vulnerability classified as problematic was found in Linux Kernel up to 6.12.29/6.14.7. This vulnerability affects the function hid_bpf_destroy_device of the component HID. The manipulation with an unknown input leads to a injection vulnerability. The CWE definition for the vulnerability is CWE-74. The product constructs all or part of a command, data structure, or record using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify how it is parsed or interpreted when it is sent to a downstream component. As an impact it is known to affect integrity. CVE summarizes:

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() when hid_ll_driver->output_report() is uninplemented (e.g., 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) Fix the issue by returning early in the two mentioned functions if hid_bpf has been marked as destroyed. Though dispatch_hid_bpf_device_event() handles input events, and there is no evidence that it may be called after the destruction, the same check, as a safety net, is also added to it to maintain the consistency among all dispatch functions. The impact of the bug on other architectures is unclear. Even if it acts as a hidden failure, this is still dangerous because it corrupts whatever is on the address calculated by SRCU. Thus, CC'ing the stable list. [1]: commit 9d7de2aa8b41 ("x86/percpu/64: Use relative percpu offsets") [2]: commit 9286675a2aed ("HID: bpf: add HID-BPF hooks for hid_hw_output_report")

The advisory is available at git.kernel.org. This vulnerability was named CVE-2025-38016 since 04/16/2025. Technical details are known, but there is no available exploit. The structure of the vulnerability defines a possible price range of USD $0-$5k at the moment (estimation calculated on 02/02/2026). This vulnerability is assigned to T1055 by the MITRE ATT&CK project.

The vulnerability scanner Nessus provides a plugin with the ID 241742 (Amazon Linux 2023 : bpftool, kernel6.12, kernel6.12-modules-extra (ALAS2023-2025-1053)), which helps to determine the existence of the flaw in a target environment.

Upgrading to version 6.12.30 or 6.14.8 eliminates this vulnerability. Applying the patch f8544be7e8e55b0ef23e1ab90e23e8d4d4aad3d3/e4b4fe25a4101d1ddb5884f40e149a3618983b66/578e1b96fad7402ff7e9c7648c8f1ad0225147c8 is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.

The vulnerability is also documented in the databases at Tenable (241742) and CERT Bund (WID-SEC-2025-1350). If you want to get best quality of vulnerability data, you may have to visit VulDB.

Affected

• Debian Linux
• Amazon Linux 2
• Red Hat Enterprise Linux
• Ubuntu Linux
• SUSE Linux
• Oracle Linux
• SUSE openSUSE
• Open Source Linux Kernel
• RESF Rocky Linux
• Dell Avamar
• Dell NetWorker
• Dell Secure Connect Gateway
• IBM QRadar SIEM

Productinfo

Type

• Operating System

Vendor

• Linux

Name

• Kernel

Version

• 6.12.0
• 6.12.1
• 6.12.2
• 6.12.3
• 6.12.4
• 6.12.5
• 6.12.6
• 6.12.7
• 6.12.8
• 6.12.9
• 6.12.10
• 6.12.11
• 6.12.12
• 6.12.13
• 6.12.14
• 6.12.15
• 6.12.16
• 6.12.17
• 6.12.18
• 6.12.19
• 6.12.20
• 6.12.21
• 6.12.22
• 6.12.23
• 6.12.24
• 6.12.25
• 6.12.26
• 6.12.27
• 6.12.28
• 6.12.29
• 6.14.0
• 6.14.1
• 6.14.2
• 6.14.3
• 6.14.4
• 6.14.5
• 6.14.6
• 6.14.7

License

• open-source

Website

• Vendor: https://www.kernel.org/

CPE 2.3info

• 🔍
• 🔍
• 🔍

CPE 2.2info

• 🔍
• 🔍
• 🔍

CVSSv4info

CVSSv3info

CVSSv2info

Exploitinginfo

Threat Intelligenceinfo

Countermeasuresinfo

Timelineinfo

Sourcesinfo

Entryinfo

If you want to get best quality of vulnerability data, you may have to visit VulDB.

Discussion