CVE-2026-31667

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Input: uinput - fix circular locking dependency with ff-core<br /> <br /> A lockdep circular locking dependency warning can be triggered<br /> reproducibly when using a force-feedback gamepad with uinput (for<br /> example, playing ELDEN RING under Wine with a Flydigi Vader 5<br /> controller):<br /> <br /> ff-&gt;mutex -&gt; udev-&gt;mutex -&gt; input_mutex -&gt; dev-&gt;mutex -&gt; ff-&gt;mutex<br /> <br /> The cycle is caused by four lock acquisition paths:<br /> <br /> 1. ff upload: input_ff_upload() holds ff-&gt;mutex and calls<br /> uinput_dev_upload_effect() -&gt; uinput_request_submit() -&gt;<br /> uinput_request_send(), which acquires udev-&gt;mutex.<br /> <br /> 2. device create: uinput_ioctl_handler() holds udev-&gt;mutex and calls<br /> uinput_create_device() -&gt; input_register_device(), which acquires<br /> input_mutex.<br /> <br /> 3. device register: input_register_device() holds input_mutex and<br /> calls kbd_connect() -&gt; input_register_handle(), which acquires<br /> dev-&gt;mutex.<br /> <br /> 4. evdev release: evdev_release() calls input_flush_device() under<br /> dev-&gt;mutex, which calls input_ff_flush() acquiring ff-&gt;mutex.<br /> <br /> Fix this by introducing a new state_lock spinlock to protect<br /> udev-&gt;state and udev-&gt;dev access in uinput_request_send() instead of<br /> acquiring udev-&gt;mutex. The function only needs to atomically check<br /> device state and queue an input event into the ring buffer via<br /> uinput_dev_event() -- both operations are safe under a spinlock<br /> (ktime_get_ts64() and wake_up_interruptible() do not sleep). This<br /> breaks the ff-&gt;mutex -&gt; udev-&gt;mutex link since a spinlock is a leaf in<br /> the lock ordering and cannot form cycles with mutexes.<br /> <br /> To keep state transitions visible to uinput_request_send(), protect<br /> writes to udev-&gt;state in uinput_create_device() and<br /> uinput_destroy_device() with the same state_lock spinlock.<br /> <br /> Additionally, move init_completion(&amp;request-&gt;done) from<br /> uinput_request_send() to uinput_request_submit() before<br /> uinput_request_reserve_slot(). Once the slot is allocated,<br /> uinput_flush_requests() may call complete() on it at any time from<br /> the destroy path, so the completion must be initialised before the<br /> request becomes visible.<br /> <br /> Lock ordering after the fix:<br /> <br /> ff-&gt;mutex -&gt; state_lock (spinlock, leaf)<br /> udev-&gt;mutex -&gt; state_lock (spinlock, leaf)<br /> udev-&gt;mutex -&gt; input_mutex -&gt; dev-&gt;mutex -&gt; ff-&gt;mutex (no back-edge)