CVE-2026-43136

What it actually does

This flaw is a local denial-of-service vulnerability in the Linux kernel Logitech HID++ driver. A malicious or emulated USB HID device can present a crafted HID report descriptor that defines a report with no valid fields. When the kernel processes that descriptor in the Logitech HID++ report-length handling path, the missing field validation can trigger a kernel crash. The practical technical outcome is loss of availability through a kernel panic or oops; it does not directly provide code execution, privilege escalation, or data disclosure based on the published description.

Why it matters to the business

Successful exploitation can abruptly crash affected Linux systems when a malicious USB device or USB gadget is connected, causing downtime, lost work, service interruption, or instability on endpoints, kiosks, lab systems, industrial workstations, and servers with exposed USB ports. The risk is most relevant where attackers, untrusted users, contractors, or visitors can physically access USB ports, or where systems interact with untrusted USB devices. This issue is not listed in CISA KEV, has very low EPSS, and has no reported mature exploit, so internet-scale exploitation is unlikely; however, the Linux kernel’s broad ecosystem prevalence means patching should still be handled through normal kernel maintenance, with higher urgency for systems exposed to physical access.

How an attack unfolds

An attacker prepares a malicious USB HID device or USB gadget capable of supplying a custom HID report descriptor. The descriptor is crafted so that a report structure lacks valid fields. The attacker then connects the device to an affected Linux system, or convinces someone with access to connect it. During USB enumeration and HID driver binding, the kernel’s Logitech HID++ driver processes the malformed descriptor and attempts to determine report length without properly handling the no-field condition. This can cause a kernel fault and crash the host. Exploitation is local and availability-focused: the attacker’s goal is to interrupt the machine rather than steal data or gain persistent access.

How to fix it

Update the Linux kernel to a version provided by the operating system or distribution vendor that includes the HID Logitech HID++ fix for validating the report field count in hidpp_get_report_length(). No universal upstream fixed package version was provided in the input, so administrators should consult their Linux distribution security advisory, kernel changelog, or vendor errata for the exact corrected kernel build. Until patching is complete, reduce exposure by restricting physical access to USB ports, disabling or locking unused USB ports in firmware/BIOS where feasible, enforcing USB device control with tools such as USBGuard, and limiting use of untrusted USB HID devices. If Logitech HID++ device support is not required, consider temporarily blacklisting or disabling the affected driver/module according to distribution guidance, while validating that doing so does not disrupt required keyboards, mice, receivers, or other peripherals.

How to confirm the fix worked

Confirm that systems are running a vendor kernel build that includes the fix for the Logitech HID++ no-field HID report handling issue. Validate through package inventory, kernel version checks, distribution errata, and changelog review rather than relying only on the upstream CVE identifier. On representative systems, verify the currently booted kernel matches the patched package and that older vulnerable kernels are not still available as default boot entries. For mitigation validation, confirm that USB device-control policies block unauthorized HID devices and that unused USB ports are disabled where required. Avoid testing with malicious HID descriptors on production systems; any functional reproduction should be performed only in an isolated lab because the expected result is a kernel crash.

Typical attack path

1. Obtain physical or local access to an affected Linux system with an accessible USB port, or access to a path where a USB gadget can be attached.
2. Prepare a malicious USB HID device or emulated USB gadget with a crafted HID report descriptor containing a report with no valid fields.
3. Connect the malicious device to the target system.
4. Allow the Linux kernel to enumerate the device and bind the relevant HID/Logitech HID++ handling path.
5. Trigger processing of the malformed report descriptor.
6. Cause a kernel oops or panic, resulting in system crash, reboot, or service disruption.

How to detect it

To assess whether this was already exploited, review kernel logs, system journals, crash dumps, and reboot records for crashes immediately following USB device insertion or HID enumeration. Useful sources include systemd journal entries from the previous boot, /var/log/kern.log, /var/log/messages, /var/log/syslog, dmesg output, kdump/vmcore records, pstore/ramoops logs, endpoint telemetry, and physical access or USB device-control logs. Look for unexpected USB HID devices, new Logitech HID++ or HID driver binding events, and kernel oops or panic stack traces referencing hidpp_get_report_length, logitech-hidpp, or HID report parsing. Correlate crash timestamps with USB connect/disconnect events, user badge/physical access logs where available, and helpdesk reports of a device being plugged in shortly before reboot. Because exploitation results in denial of service rather than persistence, indicators are most likely to be transient kernel log artifacts, crash dumps, and reboot telemetry rather than files, accounts, network beacons, or registry changes.

• hidpp_get_report_length
• logitech-hidpp
• HID: logitech-hidpp
• BUG: kernel NULL pointer dereference
• general protection fault
• Kernel panic - not syncing
• Oops:
• Call Trace:
• usbcore: registered new interface driver logitech-hidpp
• input: Logitech
• hid-generic
• USB HID v
• new full-speed USB device
• new high-speed USB device
• new SuperSpeed USB device

What your security team should do

• Prioritize patching Linux systems where attackers or untrusted users can physically access USB ports, including kiosks, shared workstations, labs, manufacturing systems, conference-room devices, and edge systems.
• Track operating system and distribution advisories for the exact fixed kernel packages and ensure systems reboot into the patched kernel after installation.
• Use endpoint inventory to identify Linux systems with accessible USB ports and Logitech HID++/HID device support enabled.
• Implement or tighten USB device-control policies, such as allowlisting trusted keyboards, mice, receivers, and other HID peripherals.
• Review kernel crash, oops, and reboot telemetry for signs of recent USB/HID-triggered failures, especially where unexpected USB devices were connected before a crash.
• For high-risk or unattended systems, disable unused USB ports through BIOS/UEFI settings, port blockers, physical controls, or host policy.
• Retain crash dumps and kernel logs for forensic review if unexplained reboots occur after USB device insertion.
• Treat this as an availability and physical-access risk rather than a remote compromise issue; align urgency with exposure to untrusted USB access.