CVE-2026-43251

What it actually does

This Linux kernel flaw is a local denial-of-service issue in the HID prodikeys driver. A malicious or emulated USB HID device can present crafted report descriptors that bypass the normal input_mapping() initialization path, leaving pm->input_ep82 unset. Later driver code assumes that pointer exists and dereferences it, causing a kernel crash or panic. The impact is limited to availability; the available information does not indicate data disclosure, privilege escalation, or code execution.

Why it matters to the business

Systems that allow local users, physical access, or attached/emulated USB devices may be crashed by a malicious peripheral, causing service interruption, unscheduled reboots, workload disruption, and potential loss of unsaved data. Risk is highest for kiosks, shared workstations, labs, build systems, embedded Linux devices, and servers where USB access is not tightly controlled. This is not listed in CISA KEV, is not reported as ransomware-used, has very low EPSS, and has no public exploit maturity indicated, so it is generally a lower-priority patching item unless the organization has exposed or untrusted USB access.

How an attack unfolds

An attacker needs local opportunity to attach or emulate a USB device that is recognized through the HID prodikeys code path. The attacker prepares a fake USB HID device with report descriptors that differ from the legitimate hardware behavior, preventing the driver's input_mapping() hook from initializing pm->input_ep82. Once the kernel continues processing the malicious device, later prodikeys logic dereferences the missing endpoint pointer. This triggers a NULL pointer dereference or similar kernel fault, resulting in an oops, panic, system crash, or device reboot depending on kernel configuration.

How to fix it

Update the Linux kernel to a version that includes the HID prodikeys fix that checks for the presence of pm->input_ep82 before use. If vendor fixed versions are not yet mapped, apply the latest stable kernel or distribution security update containing the upstream HID prodikeys patch. Where immediate patching is not possible, reduce exposure by disabling unused USB ports, enforcing physical access controls, blocking untrusted USB devices with USBGuard or equivalent allowlisting, disabling the affected prodikeys HID driver if not required, and using kernel lockdown or device-control policies appropriate for the platform.

How to confirm the fix worked

Confirm the running kernel includes the vendor or upstream fix for the HID prodikeys NULL pointer check. Validate through package manager security advisories, distribution changelogs, kernel commit history, or vendor errata referencing the prodikeys input_ep82 presence check. On Linux hosts, compare the running kernel version from uname -r with the patched package version installed by the distribution. If source-based validation is available, confirm the prodikeys driver checks pm->input_ep82 before dereference. Also verify compensating controls by confirming USB device-control policies are active and that unauthorized HID devices are blocked or logged.

Typical attack path

1. Obtain local access to a Linux system, or a path to present an emulated USB HID device to it.
2. Connect or emulate a USB device that impersonates the affected prodikeys-compatible hardware.
3. Send crafted HID report descriptors that avoid the expected input_mapping() initialization path.
4. Cause the prodikeys driver to continue operating with pm->input_ep82 unset.
5. Trigger later driver handling that dereferences the NULL endpoint pointer.
6. Crash or panic the kernel, interrupting availability of the host or appliance.

How to detect it

To determine whether exploitation may have occurred, review kernel logs, system journals, crash dumps, and endpoint telemetry for crashes occurring immediately after USB HID enumeration or prodikeys driver activity. Relevant sources include journalctl -k output, /var/log/kern.log, /var/log/messages, dmesg archives, kdump/vmcore records, apport/ABRT crash reports, audit logs, USBGuard logs, and EDR device-control events. Look for new or unusual USB HID devices, repeated connect/disconnect activity, prodikeys driver messages, NULL pointer dereference traces, kernel oops/panic events, and stack traces involving hid-prodikeys or prodikeys functions. There are no public reports of active exploitation in the provided data, so detection should focus on suspicious local USB activity and crash correlation rather than known malware infrastructure.

• prodikeys
• hid-prodikeys
• HID: prodikeys
• input_ep82
• NULL pointer dereference
• Oops:
• Kernel panic
• BUG: kernel NULL pointer dereference
• usbcore: registered new interface driver hid-prodikeys
• USB HID
• new full-speed USB device
• new high-speed USB device
• /var/log/kern.log
• /var/log/messages
• /var/crash/
• /proc/vmcore

What your security team should do

• Patch affected Linux kernels during the next appropriate maintenance cycle, with accelerated handling for shared, physically accessible, embedded, kiosk, OT, lab, or high-availability systems with usable USB ports.
• Inventory systems that load or include the HID prodikeys driver and identify where physical or emulated USB attachment is possible.
• Implement or tighten USB device allowlisting, especially for servers and workstations where arbitrary HID devices should not be trusted.
• Disable unused physical USB ports in firmware, operating system policy, or endpoint management where operationally feasible.
• Monitor kernel logs for HID prodikeys crashes or NULL pointer dereferences correlated with new USB device enumeration.
• Treat repeated unexplained kernel crashes after USB insertion as potentially malicious until ruled out.
• Because this issue is not KEV-listed, not ransomware-associated, and has low EPSS, prioritize based on physical-access risk rather than internet exposure.