CVE-2026-64362

What it actually does

This is a Linux kernel use-after-free in the HID Logitech G15/G15 v2/G510 keyboard driver. The driver schedules asynchronous work in response to certain HID input events, but prior to the fix it did not cancel that pending work when the device was removed. If the device is unplugged while the work item is pending or running, devres can free the driver state while the queued worker later dereferences it via container_of(), causing a kernel memory safety violation. The most likely impact is a local kernel crash or denial of service; depending on timing, allocator behavior, kernel hardening, and attacker control over a malicious or emulated HID device, kernel memory corruption could potentially be explored for privilege escalation, but no public exploit maturity is indicated and EPSS is very low.

Why it matters to the business

Systems that use affected Linux kernel versions with the lg-g15 HID driver exposed to physical or USB-accessible Logitech G-series keyboards, or to malicious USB/HID emulation, could be crashed through device removal timing. The operational risk is highest for workstations, kiosks, lab systems, industrial consoles, or servers where untrusted USB devices can be connected. Because exploitation requires local device interaction or equivalent USB/HID access and this is not in CISA KEV, broad internet-scale exploitation is unlikely; however, kernel crashes can still cause downtime, data loss from abrupt reboots, and disruption of endpoints used for critical operations.

How an attack unfolds

An attacker needs local physical access, control of an attached vulnerable HID device, or the ability to present a malicious/emulated USB HID device to the target. They trigger one of the driver paths that schedules the lg-g15 asynchronous work item, such as sending the relevant keyboard/backlight or LED-related report event for G15, G15 v2, or G510 models. Before the work item completes, the attacker causes device removal, for example by unplugging the device or emulating a USB disconnect. On vulnerable kernels, device-managed memory for the driver state can be freed while the queued worker still exists. When the workqueue later runs or continues running, it dereferences freed memory, causing a use-after-free. In common scenarios this results in a kernel oops, panic, or system instability; in a more advanced scenario, an attacker would try to shape kernel heap reuse around the race to influence freed memory contents.

How to fix it

Upgrade to a Linux kernel build that includes the fix adding a remove callback that cancels pending lg-g15 work before device-managed state is freed. If vendor kernels are used, apply the relevant distribution kernel update rather than attempting to cherry-pick manually unless you maintain a custom kernel. No exact fixed package versions were provided in the input, so consult the Linux kernel stable tree and the relevant OS vendor advisory for the corrected kernel release. As interim mitigations, restrict physical/USB access to systems, disable or block untrusted USB HID devices using USB authorization/udev policy, avoid exposing USB passthrough to untrusted virtual machines, and consider disabling or not loading the lg-g15 driver where these devices are not needed.

How to confirm the fix worked

Confirm the running kernel includes the upstream/vendor fix for the HID lg-g15 remove path that cancels pending work before devres cleanup. Validate by checking the installed kernel package against the distribution advisory or by reviewing source/build metadata for the lg-g15 driver fix. On custom kernels, verify the driver has a remove callback and calls cancel_work_sync() conditionally for initialized work. Confirm exposure by checking whether the lg-g15 driver/module is present or loaded and whether Logitech G15/G15 v2/G510-class devices are attached or permitted. After patching, reboot into the updated kernel and verify the active kernel version with uname -a and package manager inventory.

Typical attack path

1. Gain local physical access to the Linux system, or gain the ability to attach/emulate a USB HID device to it.
2. Present a Logitech G15/G15 v2/G510-compatible HID device or crafted HID emulation handled by the lg-g15 driver.
3. Send an input/report event that causes the driver to schedule its asynchronous work item.
4. Rapidly disconnect or emulate removal of the HID device before the queued work is cancelled or completes.
5. Cause the stale workqueue callback to dereference freed driver state.
6. Observe or attempt to leverage the resulting kernel use-after-free, most commonly as a crash/denial of service.

How to detect it

Review kernel logs and centralized endpoint telemetry for evidence of crashes, memory-safety reports, or repeated USB HID attach/detach events involving the lg-g15 driver. Relevant sources include journald, /var/log/kern.log, /var/log/messages, dmesg output, crash dumps, kdump/vmcore records, EDR device-control telemetry, and USB authorization logs. Look for KASAN or kernel oops messages referencing use-after-free, workqueues, HID, lg-g15, or Logitech G15/G510 devices. Also look for suspicious sequences where a Logitech G-series HID device generates reports and is immediately disconnected repeatedly. Because exploitation is race-based and local/USB-mediated, durable network indicators are not expected. Absence of logs does not prove absence of exploitation if kernel logs rotated or the crash prevented log flushing.

• lg-g15
• lg_g15
• lg_g15_event
• lg_g15_v2_event
• lg_g510_leds_event
• HID: lg-g15
• KASAN: use-after-free
• BUG: KASAN: slab-use-after-free
• BUG: unable to handle kernel paging request
• kernel NULL pointer dereference
• general protection fault
• Workqueue:
• cancel_work_sync
• Logitech G15
• Logitech G510
• G15 v2
• usb disconnect
• USB disconnect, device number
• hid-generic
• /var/log/kern.log
• /var/log/messages
• /var/crash
• /proc/modules

What your security team should do

• Prioritize kernel updates for Linux endpoints where local users can attach USB devices, especially shared workstations, kiosks, labs, and operational technology consoles.
• Inventory systems with the lg-g15 driver available or loaded and systems allowing untrusted USB HID devices.
• Apply vendor kernel updates and reboot into the fixed kernel; kernel package installation alone is not sufficient until the vulnerable kernel is no longer running.
• Where immediate patching is not possible, enforce USB device control, disable unused HID devices, and restrict USB passthrough to virtual machines.
• Monitor kernel logs for HID lg-g15 errors, KASAN use-after-free reports, kernel oops/panic events, and suspicious USB connect/disconnect patterns.
• Treat unexpected crashes correlated with Logitech G-series keyboard attach/detach events as potential exploitation or reliability abuse and preserve logs for analysis.