CVE-2026-31667: Linux Kernel Race Condition Vulnerability

CVE-2026-31667 Overview

A circular locking dependency vulnerability has been identified in the Linux kernel's uinput subsystem, specifically in the interaction between the uinput driver and the force-feedback (ff-core) module. This race condition vulnerability can be triggered when using force-feedback gamepads with uinput, leading to potential deadlock conditions and system instability.

The vulnerability manifests as a lockdep circular locking dependency warning that can be reproduced when using force-feedback gaming controllers through uinput, such as when running games under Wine with compatible controllers.

Critical Impact

Local attackers with low privileges can potentially cause system deadlocks or gain elevated privileges through exploitation of the circular mutex dependency in the Linux kernel's input subsystem.

Affected Products

• Linux Kernel versions from 2.6.19 through affected stable branches
• Linux Kernel 7.0 release candidates (rc1 through rc7)
• Systems using uinput with force-feedback gaming peripherals

Discovery Timeline

• April 24, 2026 - CVE-2026-31667 published to NVD
• April 27, 2026 - Last updated in NVD database

Technical Details for CVE-2026-31667

Vulnerability Analysis

This vulnerability is a race condition (CWE-667: Improper Locking) in the Linux kernel's input subsystem. The issue creates a circular dependency between four separate mutex locks that can lead to deadlock conditions when certain code paths are executed concurrently.

The circular dependency follows this chain: ff->mutex → udev->mutex → input_mutex → dev->mutex → ff->mutex. When these locks are acquired in different orders across different kernel code paths, a deadlock can occur, potentially freezing the system or causing denial of service conditions.

The vulnerability requires local access to exploit, making it particularly concerning for multi-user systems or environments where attackers have limited shell access and seek privilege escalation opportunities.

Root Cause

The root cause lies in improper lock acquisition ordering across four distinct kernel code paths:

1. Force-feedback upload path: The input_ff_upload() function holds ff->mutex while calling through to uinput_request_send(), which then attempts to acquire udev->mutex.

2. Device creation path: The uinput_ioctl_handler() holds udev->mutex while calling input_register_device(), which acquires input_mutex.

3. Device registration path: input_register_device() holds input_mutex while calling kbd_connect() → input_register_handle(), which acquires dev->mutex.

4. Event device release path: evdev_release() calls input_flush_device() under dev->mutex, which in turn calls input_ff_flush() that attempts to acquire ff->mutex.

This creates a complete cycle where each lock depends on another lock that may already be held, causing potential deadlock.

Attack Vector

The attack vector is local, requiring an attacker to have access to the target system. Exploitation involves:

The vulnerability can be triggered through normal usage of force-feedback gaming controllers with the uinput subsystem. An attacker with local access could potentially craft specific sequences of input device operations to deliberately trigger the deadlock condition, causing denial of service. The high confidentiality, integrity, and availability impact indicates potential for more severe exploitation if combined with other vulnerabilities.

The fix introduces a new state_lock spinlock to protect udev->state and udev->dev access in uinput_request_send() instead of acquiring udev->mutex. Since spinlocks are leaf nodes in lock ordering and cannot form cycles with mutexes, this breaks the problematic ff->mutex → udev->mutex link in the dependency chain.

Detection Methods for CVE-2026-31667

Indicators of Compromise

• Kernel log messages showing lockdep circular locking dependency warnings involving ff->mutex, udev->mutex, input_mutex, and dev->mutex
• System hangs or freezes when force-feedback gaming controllers are connected and in use
• Unexpected system instability when running applications that utilize uinput with force-feedback devices
• Kernel panic or soft lockup messages referencing the input subsystem or uinput module

Detection Strategies

• Monitor kernel logs for lockdep warnings containing references to input_ff_upload, uinput_request_send, or uinput_create_device functions
• Deploy kernel runtime verification tools to detect potential deadlock conditions in the input subsystem
• Implement system monitoring for unusual hangs or unresponsiveness when gaming peripherals are active
• Use kernel debugging options like CONFIG_PROVE_LOCKING to proactively detect lock ordering violations

Monitoring Recommendations

• Enable lockdep in development and testing environments to catch locking issues before production deployment
• Configure alerting for kernel soft lockups and hung task warnings related to input device handling
• Monitor for unusual patterns in uinput device creation and force-feedback operations
• Implement endpoint detection and response (EDR) solutions capable of monitoring kernel-level anomalies

How to Mitigate CVE-2026-31667

Immediate Actions Required

• Update to patched kernel versions containing the security fix as soon as available
• If patching is not immediately possible, consider temporarily disabling force-feedback functionality on affected systems
• Restrict local access to systems where kernel exploitation could lead to privilege escalation
• Monitor systems for signs of exploitation attempts or unusual input device behavior

Patch Information

The Linux kernel maintainers have released patches across multiple stable branches. The fix introduces a state_lock spinlock to break the circular dependency chain. Apply the appropriate patch for your kernel version:

• Kernel Git Commit 1534661043
• Kernel Git Commit 1e09dfbb4
• Kernel Git Commit 271ee71a1
• Kernel Git Commit 4cda78d6f
• Kernel Git Commit 546c18a1
• Kernel Git Commit 71a9729f4
• Kernel Git Commit 974f7b13
• Kernel Git Commit a3d6c9c0

Workarounds

• Blacklist the uinput kernel module if force-feedback functionality is not required: add blacklist uinput to /etc/modprobe.d/blacklist.conf
• Restrict access to /dev/uinput using appropriate file permissions to limit which users can interact with the uinput subsystem
• Disable force-feedback support at the application level for gaming software using Wine or similar compatibility layers
• Consider using alternative input handling mechanisms that do not rely on uinput for force-feedback functionality

# Temporary workaround: Blacklist uinput module
echo "blacklist uinput" >> /etc/modprobe.d/blacklist-uinput.conf

# Restrict access to uinput device
chmod 600 /dev/uinput
chown root:root /dev/uinput

# Verify module is not loaded
lsmod | grep uinput
# If loaded, unload with: rmmod uinput