Description

In the Linux kernel, the following vulnerability has been resolved: HID: hidpp: fix potential UAF in hidpp_connect_event() If input_register_device() fails, we call input_free_device(), but keep stale pointer to the old device in hidpp->input, which could potentially lead to UAF. Fix that by resetting it to NULL before returning from hidpp_connect_event().

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-09-24T17:17:16.297Z",
  "pubdate": "2026-09-24T17:17:16.297Z",
  "executiveSummary": "This vulnerability is a Use-After-Free (UAF) flaw residing in the Linux kernel's hidpp driver. It occurs within the hidpp_connect_event() function during the registration phase of an input device.\nThe vulnerability arises when the input_register_device() function fails, triggering an error path that frees the input device object without nullifying the pointer stored in the hidpp structure.\nThis leaves a stale pointer, which can be subsequently dereferenced by the kernel, potentially leading to system instability, kernel panics, or arbitrary code execution scenarios depending on how an attacker can influence heap object reallocation.\nThe issue affects systems utilizing the Logitech HID++ protocol implementation in the Linux kernel. Exploitation requires an attacker to trigger the error condition during device registration, which typically occurs upon device connection.\nThe primary risk is a local privilege escalation or denial-of-service, as the kernel may attempt to access memory that has already been returned to the slab allocator.",
  "technicalDetails": "The root cause of this vulnerability is improper error handling in the hidpp_connect_event() function within the HID subsystem. When a new HID++ device is connected, the driver attempts to initialize and register an input device using input_register_device().\nIf input_register_device() returns a non-zero error code, the driver proceeds to clean up by calling input_free_device(). However, the implementation fails to clear the reference to the now-freed input device object stored within the hidpp data structure (specifically hidpp->input).\nBecause the stale pointer remains in the structure, subsequent kernel operations that interact with the hidpp driver may attempt to access or operate on this pointer, assuming it is a valid, initialized input device.\nThis creates a Use-After-Free (UAF) condition. An attacker capable of triggering the failure of input_register_device()—for instance, by manipulating device descriptors or exhausting memory resources during the probe phase—can induce this state.\nOnce the UAF condition is established, the kernel may reference the memory address previously occupied by the input device. If a local attacker can trigger the allocator to place controlled or semi-controlled data into that exact memory region (a heap spray or reclamation technique), they could influence control flow or state variables associated with the HID subsystem.\nThe vulnerable code path involves the interaction between the HID driver's error handling and the input layer's lifecycle management. The failure to set hidpp->input to NULL constitutes a dangling pointer vulnerability that bypasses kernel safety checks.\nImpact ranges from a kernel oops/panic resulting in denial-of-service, to potential exploitation where an attacker could achieve arbitrary code execution by redirecting kernel control flow via the misused pointer. The vulnerability is local in scope, as it requires the ability to interact with the system's USB or HID-compatible peripheral controllers."
}