CVE-2026-43319: spi: spidev: fix lock inversion between spi_lock and buf_lock
In the Linux kernel, the following vulnerability has been resolved:
spi: spidev: fix lock inversion between spi_lock and buf_lock
The spidev driver previously used two mutexes, spi_lock and buf_lock,
but acquired them in different orders depending on the code path:
write()/read(): buf_lock -> spi_lock
ioctl(): spi_lock -> buf_lock
This AB-BA locking pattern triggers lockdep warnings and can
cause real deadlocks:
WARNING: possible circular locking dependency detected
spidev_ioctl() -> mutex_lock(&spidev->buf_lock)
spidev_sync_write() -> mutex_lock(&spidev->spi_lock)
*** DEADLOCK ***
The issue is reproducible with a simple userspace program that
performs write() and SPI_IOC_WR_MAX_SPEED_HZ ioctl() calls from
separate threads on the same spidev file descriptor.
Fix this by simplifying the locking model and removing the lock
inversion entirely. spidev_sync() no longer performs any locking,
and all callers serialize access using spi_lock.
buf_lock is removed since its functionality is fully covered by
spi_lock, eliminating the possibility of lock ordering issues.
This removes the lock inversion and prevents deadlocks without
changing userspace ABI or behaviour.
Security readout for executives and security teams
Plain-English summary
CVE-2026-43319 is a Linux kernel spidev driver locking flaw that can deadlock SPI device access. It matters most for embedded, industrial, IoT, or hardware-control systems using spidev. The sources do not show remote code execution, privilege escalation, or active exploitation.
Executive priority
Treat as a targeted availability risk. Patch during normal kernel maintenance for general fleets, but prioritize systems where local applications can access SPI devices or where SPI failure affects operations.
Technical view
The spidev driver acquired spi_lock and buf_lock in inconsistent orders across read/write and ioctl paths, creating an AB-BA deadlock risk. The fix removes buf_lock and serializes callers through spi_lock, without changing the userspace ABI or intended behavior.
Likely exposure
Exposure is likely limited to Linux systems with the spidev driver enabled and accessible to local users or applications, especially systems exposing /dev/spidev device nodes for SPI peripherals.
Exploitation context
The source states the issue is reproducible by concurrent userspace operations on the same spidev file descriptor. KEV is false, and no cited source reports active exploitation.
Researcher notes
Evidence supports a kernel-level local deadlock condition in spidev, not a remote compromise. Severity, CVSS, and CWE are absent from the supplied data, so impact assessment should remain conservative.
Mitigation direction
Apply the appropriate Linux stable kernel update containing the referenced spidev fixes.
Check distribution or device-vendor advisories for backported kernel packages.
Restrict access to spidev device nodes to trusted users and services.
Prioritize embedded or operational systems where SPI device availability is safety or business critical.
Validation and detection
Inventory systems running affected Linux kernel versions listed in the CVE data.
Confirm whether spidev is enabled and /dev/spidev devices are exposed.
Verify the relevant stable kernel fix is present or backported.
Regression-test normal SPI workloads after updating the kernel.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2026-43319 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
0CVSS vectors
3Timeline events
0ADP providers
6Source links
Vulnerability timeline
Timeline events are normalized from CVE metadata, CNA source timelines, ADP timelines, and KEV metadata when present.
CVE reservedCVE Program
The CVE ID was reserved by the assigning CNA.
CVE publishedCVE Program
The CVE record was published.
May 8, 2026, 13:26 UTC (UTC+00:00)
CVE updatedCVE Program
The CVE record metadata indicates this as the latest update time.