CVE-2026-43319: Linux Kernel Race Condition Vulnerability

CVE-2026-43319 Overview

CVE-2026-43319 is a locking flaw in the Linux kernel spidev driver that allows a local user to trigger a deadlock. The driver maintained two mutexes, spi_lock and buf_lock, and acquired them in inconsistent orders across code paths. The write() and read() paths took buf_lock before spi_lock, while the ioctl() path took them in the reverse order. This AB-BA pattern produces circular locking dependencies that lockdep flags and that can stall kernel threads holding the locks. The issue is classified under [CWE-667] Improper Locking and affects the Linux kernel through 7.0-rc7.

Critical Impact

A local, low-privileged user can deadlock kernel threads operating on a shared spidev file descriptor, producing a denial-of-service condition on systems exposing SPI devices to user space.

Affected Products

• Linux Kernel (multiple stable branches prior to fix)
• Linux Kernel 7.0-rc1 through 7.0-rc7
• Systems exposing /dev/spidev* character devices to user space

Discovery Timeline

• 2026-05-08 - CVE-2026-43319 published to NVD
• 2026-05-15 - Last updated in NVD database

Technical Details for CVE-2026-43319

Vulnerability Analysis

The spidev driver provides a user-space interface to Serial Peripheral Interface (SPI) devices through character device nodes. The driver previously serialized concurrent access using two mutexes with overlapping responsibilities. buf_lock protected the internal transfer buffers, while spi_lock protected the underlying SPI device state.

The write() and read() system call handlers acquired buf_lock first, then called spidev_sync_write() or spidev_sync_read(), which acquired spi_lock. The ioctl() handler reversed this order, acquiring spi_lock first and then taking buf_lock for buffer manipulation. When two threads operate on the same file descriptor concurrently, one performing write() and another issuing SPI_IOC_WR_MAX_SPEED_HZ, each thread can hold one lock while waiting for the other.

The upstream fix removes buf_lock entirely and consolidates serialization under spi_lock. spidev_sync() no longer performs locking, and all callers acquire spi_lock directly. This eliminates the ordering dependency without altering the userspace ABI.

Root Cause

The root cause is inconsistent lock acquisition order [CWE-667]. Two distinct call paths into the same driver acquired the same pair of mutexes in opposite sequences, satisfying the textbook AB-BA precondition for deadlock.

Attack Vector

Exploitation requires local access and the ability to open a spidev character device. An attacker spawns two threads sharing the same file descriptor. One thread issues repeated write() calls; the other issues SPI_IOC_WR_MAX_SPEED_HZ ioctls. The timing window for the lock inversion is reachable without elevated privileges beyond the standard device-node permissions.

No exploit code is required beyond the reproducer described in the upstream commit message. The vulnerability does not yield code execution or data disclosure. The impact is restricted to availability through kernel-thread deadlock.

Detection Methods for CVE-2026-43319

Indicators of Compromise

• Kernel log messages containing possible circular locking dependency detected referencing spidev_ioctl and spidev_sync_write.
• Hung-task warnings naming threads blocked in mutex_lock within spidev functions.
• Processes stuck in uninterruptible sleep (D state) when interacting with /dev/spidev* nodes.

Detection Strategies

• Enable CONFIG_PROVE_LOCKING and CONFIG_LOCKDEP on test kernels to surface circular dependency reports during QA.
• Monitor dmesg for INFO: task ... blocked for more than messages tied to SPI workloads.
• Audit running kernel versions against the fixed commits listed in the upstream advisory.

Monitoring Recommendations

• Collect kernel ring buffer output centrally and alert on lockdep warnings referencing spi_lock or buf_lock.
• Track processes accessing /dev/spidev* and correlate with hung-task telemetry from production hosts.
• Inventory embedded and IoT Linux fleets that expose SPI interfaces, since these are most likely to ship the vulnerable driver.

How to Mitigate CVE-2026-43319

Immediate Actions Required

• Apply the upstream kernel patches referenced below to all affected stable branches and rebuild custom kernels.
• Restrict permissions on /dev/spidev* nodes so that only trusted service accounts can open them.
• Identify multi-threaded user-space programs that share spidev file descriptors across read/write and ioctl calls and route operations through a single serialized worker until patched.

Patch Information

The fix is committed upstream and merged into stable trees. Reference the upstream commits: 40534d19ed2a, 41ccfac7d302, e341e1821503, and f8431b867223. Distribution maintainers will backport these to supported kernel packages.

Workarounds

• Avoid concurrent write()/read() and ioctl() operations from separate threads on the same spidev file descriptor.
• Tighten udev rules to limit access to SPI character devices to a dedicated, audited group.
• Unload the spidev module on systems that do not require user-space SPI access using modprobe -r spidev and blacklist it in /etc/modprobe.d/.

# Configuration example: blacklist spidev where not needed
echo 'blacklist spidev' | sudo tee /etc/modprobe.d/disable-spidev.conf
sudo modprobe -r spidev

# Restrict device node permissions via udev
echo 'KERNEL=="spidev*", GROUP="spi", MODE="0660"' | \
  sudo tee /etc/udev/rules.d/90-spidev.rules
sudo udevadm control --reload-rules && sudo udevadm trigger