CVE-2026-31667

What it actually does

This is a local Linux kernel race/locking flaw in the uinput and force-feedback input-device paths. A low-privileged local user who can access uinput can trigger an unsafe lock ordering cycle involving force-feedback mutexes, uinput device mutexes, the global input mutex, and per-device mutexes. The flaw can cause kernel lockups or deadlocks and includes a request-completion ordering issue where a request may become visible to the destroy path before its completion object is initialized. In the worst case, this class of bug may affect kernel memory safety and could support local privilege escalation or kernel information disclosure, although no public exploit maturity is currently reported.

Why it matters to the business

Successful exploitation requires local access, but impacted systems can suffer crashes, hangs, or possible privilege escalation from an ordinary user or compromised local process. This is most relevant on Linux workstations, gaming/desktop systems, kiosks, virtualization hosts, build systems, or containerized environments where /dev/uinput is exposed to users, containers, remote desktop components, compatibility layers, or input-emulation software. The issue is not currently listed in CISA KEV, has no known ransomware association, and has a very low, flat EPSS score, so urgency is lower than for remotely exploitable kernel flaws; however, kernel-local privilege escalation bugs should still be remediated during the next standard kernel update cycle, or sooner where untrusted users can access uinput.

How an attack unfolds

An attacker first needs local code execution on a vulnerable Linux system and access to the uinput interface, typically through /dev/uinput permissions, group membership, device passthrough, or an application that brokers virtual input devices. The attacker then creates or manipulates a virtual input device with force-feedback capability and repeatedly exercises effect upload, device creation, device release, and destroy paths to force the vulnerable lock ordering and request-completion timing. By racing these paths, the attacker may trigger a kernel deadlock, system hang, or crash. If the timing issue is further weaponized, it may provide a route to kernel memory corruption and local privilege escalation. There are no named threat actors or public exploit campaigns reported for this vulnerability at this time.

How to fix it

Upgrade the Linux kernel to a vendor-supported version that includes the uinput force-feedback locking fix for this vulnerability. No exact fixed package versions were provided in the input, so follow the relevant Linux distribution or appliance vendor advisory and install the latest available stable kernel/security update. After patching, reboot into the updated kernel and remove older vulnerable kernels where operationally feasible. As compensating controls, restrict access to /dev/uinput to only trusted users and services, remove unnecessary users from input/uinput-related groups, avoid passing /dev/uinput into containers or sandboxes, disable or blacklist the uinput module where virtual input devices are not required, and limit force-feedback/input-emulation software on multi-user systems.

How to confirm the fix worked

Confirm the running kernel is the updated kernel, not merely that the package is installed. Use distribution package tools and uname output to verify the active kernel version against the vendor advisory. Review kernel changelogs or vendor errata for the uinput force-feedback circular locking dependency fix. Validate that /dev/uinput permissions are restricted and that it is not exposed into containers, virtual machines, or untrusted user sessions unless required. On test systems with lockdep enabled, reproduce the prior force-feedback/uinput workload and confirm that circular locking dependency warnings no longer appear. Also confirm that systems rebooted successfully after kernel installation and that old vulnerable kernels are not the default boot option.

Typical attack path

1. Gain local execution on a vulnerable Linux system.
2. Confirm that the uinput kernel interface is available and accessible, commonly through /dev/uinput.
3. Create or interact with a virtual input device that supports force-feedback effects.
4. Trigger force-feedback upload, input device registration, device release, and uinput destroy paths repeatedly to hit the lock-ordering race.
5. Cause a kernel deadlock, crash, or hang; in a more advanced exploit, attempt to turn the race into local privilege escalation or kernel memory disclosure.
6. Use elevated privileges or resulting instability to disrupt operations or continue post-exploitation.

How to detect it

Retrospective detection is difficult because exploitation is local and may leave only kernel-level instability artifacts. Review kernel logs, journald, syslog, audit logs, and endpoint telemetry for signs of uinput access followed by lockdep warnings, soft lockups, hard lockups, kernel oopses, panics, or unexpected reboots. Focus on events involving /dev/uinput, force-feedback devices, evdev release paths, virtual gamepads/controllers, Wine or input-emulation tools, and repeated creation/destruction of virtual input devices. On systems using auditd or eBPF telemetry, search for processes opening /dev/uinput with write access and then issuing high volumes of ioctl operations. Investigate any untrusted process, container, or remote user session interacting with /dev/uinput. There are no public threat actor procedures or stable exploit payload indicators reported for this CVE, so detection should emphasize behavioral traces and kernel crash artifacts rather than fixed malware signatures.

• /dev/uinput
• possible circular locking dependency detected
• circular locking dependency
• ff->mutex
• udev->mutex
• input_mutex
• dev->mutex
• uinput_request_send
• uinput_request_submit
• uinput_dev_upload_effect
• input_ff_upload
• uinput_flush_requests
• input_ff_flush
• evdev_release
• input_register_device
• uinput_create_device
• uinput_destroy_device
• BUG: sleeping function called from invalid context
• kernel: soft lockup
• kernel: hard lockup
• kernel: watchdog: BUG: soft lockup
• kernel panic
• uinput:

What your security team should do

• Prioritize patching systems where untrusted local users, desktop sessions, remote desktop users, CI jobs, containers, or sandboxed workloads can access /dev/uinput.
• Deploy the latest vendor-supported Linux kernel containing the fix, then reboot and verify the running kernel version.
• Audit /dev/uinput permissions and remove broad write access; restrict it to trusted services only.
• Do not pass /dev/uinput into containers or virtualized workloads unless there is a documented business requirement and compensating controls are in place.
• Blacklist or disable the uinput module on servers that do not require virtual input devices.
• Monitor kernel logs for lockdep circular dependency warnings, uinput errors, hangs, soft lockups, and suspicious repeated virtual input device creation.
• Treat unexplained kernel crashes involving uinput, evdev, input force-feedback, or game-controller emulation as potentially security-relevant until patched.
• Because EPSS is low and there is no KEV listing or known ransomware use, handle through normal kernel security maintenance unless local multi-user exposure raises risk.