Linux Kernel CVE-2026-93826

Requires the system to run the Linux HID++ driver (hidpp) with a Logitech HID++ device (e.g., Unifying receiver, mouse, keyboard, touchpad) present, AND requires input_register_device() to fail during hidpp_connect_event() - a condition normally reached only under memory-allocation failure or internal registration errors that are not attacker-controlled. LIMITING FACTORS: the trigger is an error path that rarely executes; there is no demonstrated remote/adjacent reachability despite the AV:A rating; impact is dominated by local kernel crash/DoS rather than confidentiality or integrity compromise; local presence of the affected hardware and kernel version prior to the fixed backports (6.12.111 / 6.18.53 / 7.2) is required.

This is a HIGH-CVSS-but-LOW-real-risk issue. The input NVD/Linux CVSS v3.1 vector (7.5, AV:A/AC:H/PR:N/UI:N/C:H/I:H/A:H) is materially overstated. The description makes clear this is a 'potential' use-after-free confined to an error path: it triggers only if input_register_device() fails inside hidpp_connect_event(), after which a stale pointer (hidpp->input) is retained. That failure is driven by kernel-internal conditions (memory allocation pressure / device registration failure), NOT by attacker-supplied input, so the AV:A/PR:N/C:H/I:H/A:H rating does not reflect reality - there is no over-the-air or network reachability, and no plausible confidentiality/integrity primitive is demonstrated. EPSS, KEV, and POC signals are all absent: exploitation status is 'no public exploit identified at time of analysis,' and there is no evidence of active exploitation. The realistic worst case is a local crash/DoS on a rare error path. CONFLICT TO NOTE: CVSS claims adjacent network vector and full CIA impact, but the description describes a non-attacker-controlled driver error path - the vector appears inflated and should be treated as a latent hardening/memory-safety fix rather than an exploitable priority. The CWE is listed as N/A but this is functionally CWE-416 (use-after-free).

A local attacker or an unlucky runtime condition causes input_register_device() to fail (e.g., under memory pressure) while a Logitech HID++ device (Unifying receiver, mouse, keyboard, or touchpad) is connecting; the driver frees the input device but leaves a dangling hidpp->input pointer, which a later access can dereference. In practice this yields a kernel crash/instability rather than reliable code execution, and no public proof-of-concept exists.