CVE-2026-31667

Publish date: April 25, 2026
Severity
High
CVSS score
7.8
Package
linux
Affected versions
>= 6.1.129-1

In the Linux kernel, a vulnerability has been addressed concerning a circular locking dependency in the uinput subsystem when using force-feedback gamepads, for instance, a Flydigi Vader 5 controller during gameplay of ELDEN RING under Wine. The lockdep circular locking dependency warning arises from the following cycle due to multiple lock acquisition paths: ff->mutex -> udev->mutex -> input_mutex -> dev->mutex -> ff->mutex.The cycle is created through four main paths: first, the ff upload process where input_ff_upload() holds ff->mutex and subsequently calls uinput_dev_upload_effect(), which leads to uinput_request_submit() and uinput_request_send() and acquires udev->mutex. Second, during device creation, uinput_ioctl_handler() holds udev->mutex and invokes uinput_create_device(), progressing to input_register_device() and acquiring input_mutex. Third, in device registration, input_register_device() holds input_mutex while calling kbd_connect() and input_register_handle(), acquiring dev->mutex. Lastly, the evdev release process involves evdev_release() invoking input_flush_device() under dev->mutex, which then calls input_ff_flush() that acquires ff->mutex.To resolve this issue, a new state_lock spinlock has been introduced to protect udev->state and udev->dev access in uinput_request_send() instead of utilizing udev->mutex. This allows atomic checks on device state and queuing input events safely since the involved operations under the spinlock do not sleep. This modification breaks the previous lock cycle. Additionally, writes to udev->state in uinput_create_device() and uinput_destroy_device() are also safeguarded by the state_lock spinlock. Furthermore, the initialization of init_completion(&request->done) has been moved from uinput_request_send() to uinput_request_submit() to ensure it is set before the request is visible, allowing complete() to be called from the destroy path at any time. The lock ordering after this fix is ff->mutex -> state_lock (spinlock, leaf), udev->mutex -> state_lock (spinlock, leaf), and udev->mutex -> input_mutex -> dev->mutex -> ff->mutex (no back-edge).