Skip to main content
VulnerabilityPublished Updated

CVE-2026-31667: Linux kernel · Race Condition

Affects Linux kernelSource CVE Database V5

0

Not known to be exploited · CVSS 7.8 High · fixed in a3d6c9c053c9c605651508569230ead633b13f76 : patch Linux kernel soon.

Data as of 26 Oct 2026, 12:55 UTC

CVSS 3.1 base score
7.8High
How severe the flaw is on the 0–10 CVSS scale.
EPSS
0.09% chance of exploitation in 30 days – higher than 0% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
CISA SSVC
Exploitation
No evidence of active exploitation and no public proof of concept
Automatable
Attackers cannot reliably automate steps 1–4 of the kill chain
Technical impact
Total control over the software or total information disclosure

CISA SSVC assessment, 2026-10-16.

Patch
Available – fixed in a3d6c9c053c9c605651508569230ead633b13f76, 1534661043c434b81cfde26b97a2fb2460329cf0, 974f7b138c3a96dd5cd53d1b33409cd7b2229dc6 +5
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 24 Apr 2026

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponised: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq Mirage: no evidence on record.

    No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.

What to do

Upgrade to a fixed release listed under Affected software.

Affected software

ProductAffectedFixed in
LinuxLinuxAffected
  • ≥ ff462551235d8d7d843a005950bc90924fcedede, < a3d6c9c053c9c605651508569230ead633b13f76
Fixed in
  • a3d6c9c053c9c605651508569230ead633b13f76
LinuxLinuxAffected
  • ≥ ff462551235d8d7d843a005950bc90924fcedede, < 1534661043c434b81cfde26b97a2fb2460329cf0
Fixed in
  • 1534661043c434b81cfde26b97a2fb2460329cf0
LinuxLinuxAffected
  • ≥ ff462551235d8d7d843a005950bc90924fcedede, < 974f7b138c3a96dd5cd53d1b33409cd7b2229dc6
Fixed in
  • 974f7b138c3a96dd5cd53d1b33409cd7b2229dc6
LinuxLinuxAffected
  • ≥ ff462551235d8d7d843a005950bc90924fcedede, < 546c18a14924eb521fe168d916d7ce28f1e13c1d
Fixed in
  • 546c18a14924eb521fe168d916d7ce28f1e13c1d
LinuxLinuxAffected
  • ≥ ff462551235d8d7d843a005950bc90924fcedede, < 271ee71a1917b89f6d73ec82dd091c33d92ee617
Fixed in
  • 271ee71a1917b89f6d73ec82dd091c33d92ee617
LinuxLinuxAffected
  • ≥ ff462551235d8d7d843a005950bc90924fcedede, < 71a9729f412e2c692a35c542e14b706fb342927f
Fixed in
  • 71a9729f412e2c692a35c542e14b706fb342927f

Description

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)

References

Community reviews

Loading reviews…