CVE-2026-31667: Input: uinput - fix circular locking dependency with ff-core

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 -> inputmutex -> dev->mutex -> ff->mutex

The cycle is caused by four lock acquisition paths:

1. ff upload: inputffupload() holds ff->mutex and calls uinputdevuploadeffect() -> uinputrequestsubmit() -> uinputrequestsend(), which acquires udev->mutex.

2. device create: uinputioctlhandler() holds udev->mutex and calls uinputcreatedevice() -> inputregisterdevice(), which acquires inputmutex.

3. device register: inputregisterdevice() holds inputmutex and calls kbdconnect() -> inputregisterhandle(), which acquires dev->mutex.

4. evdev release: evdevrelease() calls inputflushdevice() under dev->mutex, which calls inputffflush() acquiring ff->mutex.

Fix this by introducing a new statelock spinlock to protect udev->state and udev->dev access in uinputrequestsend() instead of acquiring udev->mutex. The function only needs to atomically check device state and queue an input event into the ring buffer via uinputdevevent() -- both operations are safe under a spinlock (ktimegetts64() and wakeupinterruptible() 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 uinputrequestsend(), protect writes to udev->state in uinputcreatedevice() and uinputdestroydevice() with the same statelock spinlock.

Additionally, move initcompletion(&request->done) from uinputrequestsend() to uinputrequestsubmit() before uinputrequestreserveslot(). Once the slot is allocated, uinputflushrequests() 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 -> statelock (spinlock, leaf) udev->mutex -> statelock (spinlock, leaf) udev->mutex -> inputmutex -> dev->mutex -> ff->mutex (no back-edge)