CVE-2026-43111

What it actually does

This is a local use-after-free vulnerability in the Linux kernel HID Roccat driver. The vulnerable code iterates over the Roccat device reader list in roccat_report_event() without holding the readers_lock mutex, while roccat_release() can concurrently remove and free an entry from that same list. A local attacker who can interact with the affected Roccat HID device interface may be able to trigger a race condition that causes the kernel to access freed memory. Depending on heap state and exploit reliability, this can lead to kernel memory corruption, denial of service, information disclosure, or local privilege escalation to kernel-level execution.

Why it matters to the business

Systems running affected Linux kernels may be exposed to local privilege escalation or system crashes if an attacker already has low-privileged access and can reach the affected HID Roccat device path. The primary operational risk is that a compromised user account, malicious local process, or attacker with physical/USB access could turn limited access into full control of the host. The CVSS score is high, but EPSS is currently very low, it is not listed in CISA KEV, and no public exploit maturity is reported, so remediation should be prioritized through normal kernel patching programs, with higher urgency for shared workstations, developer endpoints, kiosks, lab systems, and environments where untrusted users or USB peripherals are allowed.

How an attack unfolds

An attacker first obtains local code execution as an unprivileged user on a Linux system with the vulnerable Roccat HID kernel driver available and an affected compatible HID device present or emulated. The attacker opens the Roccat character/device interface to create reader state, then deliberately races two actions: one path causes Roccat input reports to be processed through roccat_report_event(), while another path closes or releases the reader through roccat_release(). Because the vulnerable report path walks the shared readers list without holding the appropriate mutex, the release path can remove and free a reader while the report path still references it. With careful timing, heap grooming, and repeated attempts, the attacker may convert the use-after-free into controlled kernel memory corruption. Successful exploitation could crash the kernel or, in a more advanced exploit, alter kernel control/data structures to gain elevated privileges.

How to fix it

Apply a Linux kernel update that includes the upstream fix for the Roccat HID reader-list locking issue, specifically the change that protects roccat_report_event() traversal with readers_lock. Because no exact fixed versions were provided, use the latest security-supported kernel from the relevant Linux distribution or vendor and confirm that the HID Roccat fix is included in the package changelog or kernel source. Reboot systems after kernel updates so the patched kernel is active. Where immediate patching is not possible, reduce exposure by disabling or blacklisting the Roccat HID driver if it is not required, restricting use of untrusted USB/HID devices, limiting local shell access, and applying device-control policies that prevent untrusted users from attaching or emulating HID peripherals. Mitigations should not be treated as complete substitutes for the kernel fix.

How to confirm the fix worked

Confirm the system is running a patched kernel, not merely that a patched package is installed. Validate with uname -r, distribution package metadata, and vendor advisories/changelogs for the kernel build in use. If source or debug symbols are available, confirm the Roccat driver code path protects the readers list traversal in roccat_report_event() with readers_lock. Check whether the Roccat HID module is present or loaded using lsmod, modinfo, and /sys/module. If the driver is not needed and mitigation is used, verify that module blacklisting or device-control policy prevents hid-roccat-related modules from loading after reboot. For exposure assessment, inventory Linux endpoints and servers for affected kernel versions, loaded Roccat HID modules, and permitted access to HID/USB devices.

Typical attack path

1. Gain local, low-privileged access to a Linux system running an affected kernel.
2. Identify that the Roccat HID driver/device interface is present or attach/emulate a compatible Roccat HID device where local policy permits.
3. Open the Roccat device interface to create reader objects in kernel memory.
4. Trigger HID report processing while concurrently closing/releasing the reader object from another thread or process.
5. Win the race so roccat_report_event() accesses a reader object after roccat_release() has removed and freed it.
6. Use repeated racing and heap shaping to cause a kernel crash or attempt privilege escalation through kernel memory corruption.

How to detect it

There are no known public exploitation indicators specific to this issue, and successful exploitation may leave only generic kernel memory-corruption artifacts. Review kernel logs and persistent journal data for signs of HID Roccat driver faults, use-after-free warnings, lock/race-related crashes, general protection faults, kernel oops/panic events, KASAN reports, or suspicious activity around Roccat HID devices. Useful sources include dmesg output, /var/log/kern.log, /var/log/messages, /var/log/syslog, systemd-journald kernel entries, crash dumps, kdump/vmcore data, auditd process execution logs, and USB/device attach logs. Investigate events where a local process repeatedly opens/closes Roccat device nodes while HID reports are generated, especially if followed by kernel instability or privilege changes. If endpoint telemetry is available, hunt for unusual local programs interacting with /dev nodes associated with Roccat devices, repeated module load/unload activity, or unexpected attachment of Roccat-compatible USB HID devices. Absence of these artifacts does not prove non-exploitation because kernel memory-corruption exploitation can be log-sparse.

• BUG: KASAN: use-after-free
• use-after-free in roccat_report_event
• roccat_report_event
• roccat_release
• hid-roccat
• roccat
• /dev/roccat
• general protection fault
• kernel BUG
• Oops:
• Kernel panic
• Unable to handle kernel paging request
• usbcore: registered new interface driver roccat
• /sys/module/hid_roccat
• hid_roccat

What your security team should do

• Patch affected Linux kernels through the standard emergency or high-priority kernel update process, prioritizing multi-user systems and endpoints where untrusted local users or USB peripherals are allowed.
• Reboot after patching and verify the patched kernel is the one actively running.
• Inventory systems for loaded or available Roccat HID driver modules and determine whether the hardware support is required.
• If Roccat device support is unnecessary, blacklist or disable the relevant Roccat HID driver/module as a compensating control.
• Restrict local interactive access and enforce least privilege on Linux systems until patched.
• Apply USB/HID device-control policies on endpoints where physical access or untrusted peripherals are a realistic threat.
• Monitor kernel logs for crashes, KASAN use-after-free reports, or anomalous hid-roccat activity, especially on systems with local user access.
• Because this is not currently in KEV and has very low EPSS, track it in normal vulnerability management queues unless local privilege escalation risk is elevated in the environment.