CVE-2026-43319

What it actually does

This is a local availability vulnerability in the Linux kernel spidev driver caused by inconsistent mutex acquisition order between spi_lock and buf_lock. Concurrent userspace operations against the same spidev device can acquire the locks in opposite order, creating an AB-BA deadlock. A local user with permission to access a /dev/spidev* device can trigger the condition by racing read or write operations with ioctl operations such as SPI_IOC_WR_MAX_SPEED_HZ. Successful exploitation can hang the affected kernel execution path and disrupt SPI device access, with potential broader system availability impact depending on how the SPI device is used by the platform.

Why it matters to the business

Systems that expose spidev devices to local users or applications may be susceptible to denial-of-service conditions that can interrupt hardware communication, embedded control functions, industrial interfaces, sensors, peripheral management, or other SPI-backed operations. The risk is most relevant for embedded Linux, IoT, industrial, appliance, and hardware-integrated systems where SPI communication is operationally important. The vulnerability is not known to be in CISA KEV, is not reported as used in ransomware campaigns, and has very low EPSS, so broad internet-scale exploitation is unlikely; however, local misuse or faulty applications could still cause operational outages.

How an attack unfolds

An attacker first obtains local code execution or access to an account that can open an affected spidev character device, typically exposed as /dev/spidevB.C. The attacker then opens the same spidev file descriptor or device from a multithreaded program. One thread repeatedly performs read or write operations, which historically acquired buf_lock before spi_lock. Another thread repeatedly performs ioctl operations such as SPI_IOC_WR_MAX_SPEED_HZ, which acquired spi_lock before buf_lock. Under the right timing, each thread holds one mutex and waits for the other, causing a circular lock dependency and deadlock. The result is a denial-of-service condition affecting spidev operations and potentially applications or system functions that depend on SPI communication.

How to fix it

Apply a Linux kernel update that includes the spidev locking fix removing the lock inversion between spi_lock and buf_lock. Because no exact fixed package versions were provided, use the patched kernel versions supplied by the relevant Linux distribution, embedded platform vendor, device manufacturer, or kernel maintainer. Prioritize systems where /dev/spidev* devices are present and accessible to non-root users, containers, application service accounts, or untrusted local workloads. If immediate patching is not possible, restrict access to /dev/spidev* device nodes using Unix permissions, udev rules, group membership, device cgroups, container device policies, or MAC controls such as SELinux or AppArmor. Avoid exposing spidev devices into containers or sandboxes unless required. Where practical, limit local users and applications capable of issuing SPI ioctl calls until patched.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel version or vendor kernel build includes the spidev locking fix for this issue. Check distribution advisories, kernel changelogs, or package metadata for the relevant backport rather than relying only on upstream version numbers. Validate exposure by checking whether spidev is enabled and device nodes exist using commands such as ls /dev/spidev* and lsmod | grep spidev. Review device permissions to ensure only trusted users or services can access spidev nodes. On test systems, a controlled reproducer that races write() calls with SPI_IOC_WR_MAX_SPEED_HZ ioctl() calls against the same spidev device should no longer produce lockdep circular-lock warnings or hangs after patching. Do not run stress reproducers on production systems because they may intentionally trigger denial of service.

Typical attack path

1. Gain local shell, local application execution, or another way to run code on a Linux system using the affected kernel spidev driver.
2. Identify an accessible SPI userspace device such as /dev/spidev0.0 or another /dev/spidev* node.
3. Open the spidev device with sufficient permissions.
4. Start concurrent threads or processes against the same spidev device or file descriptor.
5. Continuously issue write() or read() operations from one execution path.
6. Continuously issue SPI ioctl operations such as SPI_IOC_WR_MAX_SPEED_HZ from another execution path.
7. Trigger the lock inversion between spi_lock and buf_lock, causing a deadlock.
8. Disrupt SPI communication or dependent local services until the condition is cleared, often requiring service restart or system reboot depending on impact.

How to detect it

To determine whether this was already triggered, review kernel and system logs for lockdep warnings, hung-task reports, blocked processes, or deadlock messages involving spidev_ioctl, spidev_sync_write, spidev_sync, spi_lock, or buf_lock. Relevant sources include dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, /var/log/syslog, crash dumps, kernel oops logs, watchdog reset logs, and embedded device persistent logs. Look for warning text indicating a possible circular locking dependency or AB-BA deadlock. Correlate kernel warnings with process accounting, auditd, eBPF telemetry, EDR process events, or shell history showing local programs opening /dev/spidev* and issuing heavy concurrent read/write/ioctl activity. For containers, review runtime configuration and audit logs for device passthrough of /dev/spidev* and processes inside containers accessing those nodes. Because this is a local denial-of-service issue, network IOCs are not expected; detection should focus on host logs, kernel diagnostics, device access telemetry, and unexplained service or device hangs involving SPI communication.

• WARNING: possible circular locking dependency detected
• *** DEADLOCK ***
• spidev_ioctl() -> mutex_lock(&spidev->buf_lock)
• spidev_sync_write() -> mutex_lock(&spidev->spi_lock)
• spidev_ioctl
• spidev_sync_write
• spidev_sync
• spi_lock
• buf_lock
• /dev/spidev
• /dev/spidev0.0
• /dev/spidev0.1
• SPI_IOC_WR_MAX_SPEED_HZ
• possible circular locking dependency detected
• INFO: task
• blocked for more than
• hung_task
• lockdep
• spidev

What your security team should do

• Inventory Linux systems, embedded devices, appliances, and containers that expose /dev/spidev* device nodes.
• Prioritize patching on systems where SPI controls operationally important hardware or where local users, containers, or application accounts can access spidev devices.
• Apply vendor-provided kernel updates that include the spidev deadlock fix; reboot into the patched kernel where required.
• Restrict /dev/spidev* access to the minimum required users and services using device permissions, udev rules, groups, cgroups, SELinux, AppArmor, or container runtime policy.
• Remove unnecessary spidev exposure from containers, build agents, kiosks, lab systems, and multi-user hosts.
• Monitor kernel logs for lockdep circular locking warnings, spidev deadlock messages, blocked tasks, or hung tasks involving spidev functions.
• For embedded and operational technology deployments, coordinate patch windows because remediation may require rebooting devices that control physical peripherals.
• Treat unexpected spidev stress activity or repeated ioctl/write access from untrusted local processes as suspicious even though public exploit maturity is currently reported as none.