CVE-2026-43049

What it actually does

This vulnerability is a local Linux kernel use-after-free in the Logitech HID++ driver path for the Logitech G920 Driving Force Racing Wheel for Xbox One. If force-feedback initialization fails during device probing, the driver can return an error before sysfs and /dev/input userspace interfaces are fully torn down. A local user process that keeps using references to those now-dangling input device objects can trigger memory corruption in kernel context. Because the affected code runs in the kernel, successful exploitation can potentially lead to kernel crash, denial of service, information disclosure, or local privilege escalation, depending on kernel configuration, heap state, mitigations, and exploit reliability.

Why it matters to the business

The main business risk is local compromise or instability of Linux systems that allow untrusted local users, workloads, or interactive sessions and that can interact with affected Logitech HID hardware or similar exposed HID input paths. Exploitation could allow a low-privileged local user to crash a workstation, kiosk, lab system, gaming/simulation rig, or specialized endpoint, and in a worst case gain elevated privileges on the host. This is not listed in CISA KEV, has no known public exploit maturity in the supplied data, and has a very low EPSS score with a flat 30-day trend, so broad internet-scale exploitation is unlikely; however, kernel memory-safety flaws should still be remediated during normal kernel patch cycles, especially on multi-user systems or devices with physical/peripheral access exposure.

How an attack unfolds

An attacker first needs local code execution or an account on an affected Linux system, and practical exploitation also depends on the affected Logitech HID++ device path being reachable, typically through physical or passthrough access to a Logitech G920 Racing Wheel or equivalent HID setup that exercises the vulnerable probe path. The attacker triggers a force-feedback initialization failure during driver probing. Because the vulnerable kernel returns an error before completely removing userspace-visible input infrastructure, stale sysfs and /dev/input references may remain available briefly or be retained by userspace. The attacker then uses a process to continue operating on those stale references, causing the kernel to dereference freed memory. With only a crash primitive, this results in a local denial of service. With carefully controlled heap grooming and a reliable primitive, an attacker may be able to convert the use-after-free into kernel memory corruption and privilege escalation.

How to fix it

Update the Linux kernel to a version that contains the upstream fix for the Logitech HID++ force-feedback initialization failure handling. The corrected behavior treats the force-feedback initialization failure as non-fatal and keeps the input device functional without force feedback, avoiding premature teardown and dangling userspace references. If vendor-specific fixed package versions are not yet available, track the relevant distribution kernel advisories and install the next security or stable kernel update that includes the fix. Where immediate patching is not possible, reduce exposure by restricting local shell access, disabling untrusted access to /dev/input and relevant sysfs HID/input paths, avoiding passthrough of affected HID devices into untrusted VMs or containers, limiting physical peripheral access, and considering temporary blocklisting or removal of the Logitech HID++ driver on systems that do not require affected devices.

How to confirm the fix worked

Confirm remediation by verifying the running kernel version and distribution package changelog include the HID logitech-hidpp fix for force-feedback initialization failure handling. Reboot into the patched kernel after installation; merely installing the package is insufficient if the vulnerable kernel remains running. On systems that use Logitech G920 devices, test hot-plug and driver probing while monitoring dmesg or journald for kernel warnings, KASAN reports, use-after-free messages, oopses, or crashes. Validate that the device either works without force feedback when initialization fails or is cleanly handled without leaving unstable /dev/input or sysfs references. For mitigation validation, confirm untrusted users and workloads cannot open the relevant /dev/input/event* devices or access HID sysfs paths, and confirm affected USB/HID devices are not passed through to untrusted virtualized or containerized environments.

Typical attack path

1. Obtain local access to an affected Linux system as an unprivileged user or through a local process/container with sufficient device access.
2. Ensure the affected Logitech HID++ input device path is present or can be hot-plugged/passed through to the host.
3. Trigger the Logitech G920 force-feedback initialization failure during HID device probing.
4. Retain or rapidly access userspace-visible sysfs or /dev/input references associated with the partially initialized input device.
5. Perform reads, writes, ioctls, polling, or event operations against the dangling input interfaces to trigger the use-after-free.
6. Cause a kernel crash or attempt heap manipulation to gain code execution or elevated privileges in kernel context.

How to detect it

To determine whether this was already exploited, review kernel and system logs for evidence of HID probing failures followed by use-after-free, kernel oops, panic, KASAN, slab corruption, or unexpected reboots. Relevant log sources include dmesg, journald, /var/log/kern.log, /var/log/messages, auditd logs, endpoint telemetry, USB device history, and crash dump infrastructure such as kdump or systemd-coredump where applicable. Focus on events involving the logitech-hidpp driver, HID++ devices, Logitech G920, force-feedback initialization, /dev/input/event* access, and sysfs input device access. Correlate suspicious kernel faults with local user sessions, device hot-plug events, VM/container device passthrough activity, and processes opening input devices. Because exploitation is local and may leave only crash artifacts, absence of a clear exploit string does not prove absence of exploitation; repeated kernel crashes around Logitech HID probing or input event access should be treated as suspicious.

• logitech-hidpp
• hid_logitech_hidpp
• Logitech G920
• G920 Driving Force Racing Wheel
• HID++
• force feedback
• force-feedback
• use-after-free
• KASAN: use-after-free
• BUG: KASAN: use-after-free
• kernel BUG at
• Oops:
• general protection fault
• slab-use-after-free
• /dev/input/event
• /sys/class/input
• /sys/bus/hid/devices
• /sys/module/hid_logitech_hidpp
• hidpp_ff_init
• logitech-hidpp:

What your security team should do

• Inventory Linux endpoints, kiosks, workstations, lab systems, simulation systems, and virtual hosts that permit local users or peripheral passthrough and may use Logitech HID++ devices, especially Logitech G920 Racing Wheel hardware.
• Prioritize patching multi-user Linux systems and systems where untrusted users, containers, VMs, or remote desktop sessions can access input devices.
• Deploy vendor kernel updates when available and ensure systems reboot into the fixed kernel.
• Until patched, restrict permissions on /dev/input/event* devices and HID sysfs paths to trusted users and services only.
• Disable USB/HID passthrough to untrusted VMs or containers unless explicitly required.
• Review kernel logs for use-after-free, KASAN, oops, or panic events involving logitech-hidpp, HID++, force feedback, or Logitech G920 devices.
• Consider blocklisting the affected Logitech HID++ module on systems that do not require Logitech HID++ device support.
• Treat any successful local kernel exploitation indicators as a host compromise event and perform full endpoint forensic triage.