CVE-2026-31667

Summary

In the Linux kernel, the following vulnerability has been resolved:

Input: uinput - fix circular locking dependency with ff-core

A lockdep circular locking dependency warning can be triggered reproducibly when using a force-feedback gamepad with uinput (for example, playing ELDEN RING under Wine with a Flydigi Vader 5 controller):

ff->mutex -> udev->mutex -> input_mutex -> dev->mutex -> ff->mutex

The cycle is caused by four lock acquisition paths:

  1. ff upload: input_ff_upload() holds ff->mutex and calls uinput_dev_upload_effect() -> uinput_request_submit() -> uinput_request_send(), which acquires udev->mutex.

  2. device create: uinput_ioctl_handler() holds udev->mutex and calls uinput_create_device() -> input_register_device(), which acquires input_mutex.

  3. device register: input_register_device() holds input_mutex and calls kbd_connect() -> input_register_handle(), which acquires dev->mutex.

  4. evdev release: evdev_release() calls input_flush_device() under dev->mutex, which calls input_ff_flush() acquiring ff->mutex.

Fix this by introducing a new state_lock spinlock to protect udev->state and udev->dev access in uinput_request_send() instead of acquiring udev->mutex. The function only needs to atomically check device state and queue an input event into the ring buffer via uinput_dev_event() – both operations are safe under a spinlock (ktime_get_ts64() and wake_up_interruptible() do not sleep). This breaks the ff->mutex -> udev->mutex link since a spinlock is a leaf in the lock ordering and cannot form cycles with mutexes.

To keep state transitions visible to uinput_request_send(), protect writes to udev->state in uinput_create_device() and uinput_destroy_device() with the same state_lock spinlock.

Additionally, move init_completion(&request->done) from uinput_request_send() to uinput_request_submit() before uinput_request_reserve_slot(). Once the slot is allocated, uinput_flush_requests() may call complete() on it at any time from the destroy path, so the completion must be initialised before the request becomes visible.

Lock ordering after the fix:

ff->mutex -> state_lock (spinlock, leaf) udev->mutex -> state_lock (spinlock, leaf) udev->mutex -> input_mutex -> dev->mutex -> ff->mutex (no back-edge)

Affected Software

VendorProductVersion RangeStatus
LinuxLinuxff462551235d8d7d843a005950bc90924fcedede < 71a9729f412e2c692a35c542e14b706fb342927faffected
LinuxLinuxff462551235d8d7d843a005950bc90924fcedede < 271ee71a1917b89f6d73ec82dd091c33d92ee617affected
LinuxLinuxff462551235d8d7d843a005950bc90924fcedede < 974f7b138c3a96dd5cd53d1b33409cd7b2229dc6affected
LinuxLinuxff462551235d8d7d843a005950bc90924fcedede < 546c18a14924eb521fe168d916d7ce28f1e13c1daffected
LinuxLinuxff462551235d8d7d843a005950bc90924fcedede < a3d6c9c053c9c605651508569230ead633b13f76affected
LinuxLinuxff462551235d8d7d843a005950bc90924fcedede < 1e09dfbb4f5d20ee111f92325a00f85778a5f328affected
LinuxLinuxff462551235d8d7d843a005950bc90924fcedede < 1534661043c434b81cfde26b97a2fb2460329cf0affected
LinuxLinuxff462551235d8d7d843a005950bc90924fcedede < 4cda78d6f8bf2b700529f2fbccb994c3e826d7c2affected
LinuxLinux2.6.19affected
LinuxLinux0 < 2.6.19unaffected
LinuxLinux5.10.253 <= 5.10.*unaffected
LinuxLinux5.15.203 <= 5.15.*unaffected
LinuxLinux6.1.169 <= 6.1.*unaffected
LinuxLinux6.6.135 <= 6.6.*unaffected
LinuxLinux6.12.82 <= 6.12.*unaffected
LinuxLinux6.18.23 <= 6.18.*unaffected
LinuxLinux6.19.13 <= 6.19.*unaffected
LinuxLinux7.0 <= *unaffected

Weaknesses

References