Description
In the Linux kernel, the following vulnerability has been resolved:

spi: microchip-core-qspi: control built-in cs manually

The coreQSPI IP supports only a single chip select, which is
automagically operated by the hardware - set low when the transmit
buffer first gets written to and set high when the number of bytes
written to the TOTALBYTES field of the FRAMES register have been sent on
the bus. Additional devices must use GPIOs for their chip selects.
It was reported to me that if there are two devices attached to this
QSPI controller that the in-built chip select is set low while linux
tries to access the device attached to the GPIO.

This went undetected as the boards that connected multiple devices to
the SPI controller all exclusively used GPIOs for chip selects, not
relying on the built-in chip select at all. It turns out that this was
because the built-in chip select, when controlled automagically, is set
low when active and high when inactive, thereby ruling out its use for
active-high devices or devices that need to transmit with the chip
select disabled.

Modify the driver so that it controls chip select directly, retaining
the behaviour for mem_ops of setting the chip select active for the
entire duration of the transfer in the exec_op callback. For regular
transfers, implement the set_cs callback for the core to use.

As part of this, the existing setup callback, mchp_coreqspi_setup_op(),
is removed. Modifying the CLKIDLE field is not safe to do during
operation when there are multiple devices, so this code is removed
entirely. Setting the MASTER and ENABLE fields is something that can be
done once at probe, it doesn't need to be re-run for each device.
Instead the new setup callback sets the built-in chip select to its
inactive state for active-low devices, as the reset value of the chip
select in software controlled mode is low.
Published: 2026-05-28
Score: n/a
EPSS: < 1% Very Low
KEV: No
Impact: n/a
Action: n/a
AI Analysis

Impact

The vulnerability resides in the microchip-core-qspi driver of the Linux kernel, where the built‑in chip select is automatically driven by hardware rather than being controlled directly by software. When two SPI devices are attached, the automatic chip select remains active while the driver attempts to communicate with a device whose chip select is controlled by GPIO, so the wrong device is addressed. This results in either corrupted data being sent to the unintended device or failure to access the intended device, which can degrade system availability and data integrity.

Affected Systems

All Linux kernels employing the microchip‑core‑qspi driver, notably those that connect multiple SPI devices to the same controller. Devices that rely on the built‑in chip select for active‑high operation or need the chip select disabled during transfer are most susceptible.

Risk and Exploitability

No CVSS score is provided and the EPSS is not available, and the vulnerability is not listed in CISA KEV. Due to the lack of a publicly known exploit path, the exploitation likelihood is uncertain. However, the flaw allows an attacker with the ability to access the SPI bus or influence the driver to trigger incorrect device selection, potentially leading to data corruption, denial of service, or unintended operation of peripheral devices. The inferred attack vector is local and requires access to the device tree or system configuration that controls SPI devices. The flaw remains critical for systems that depend on accurate chip‑select handling for bus reliability.

Generated by OpenCVE AI on May 28, 2026 at 11:41 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Apply the kernel patch that implements manual chip‑select control for the microchip‑core‑qspi driver.
  • Reconfigure all SPI devices that are connected to the controller to use GPIOs for chip select and disable reliance on the built‑in chip select.
  • Avoid configuring active‑high devices to use the built‑in chip select; if required, disable it in software control mode by setting it to its inactive low state during operation.

Generated by OpenCVE AI on May 28, 2026 at 11:41 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Thu, 28 May 2026 12:00:00 +0000

Type Values Removed Values Added
Weaknesses CWE-665

Thu, 28 May 2026 10:15:00 +0000

Type Values Removed Values Added
Description In the Linux kernel, the following vulnerability has been resolved: spi: microchip-core-qspi: control built-in cs manually The coreQSPI IP supports only a single chip select, which is automagically operated by the hardware - set low when the transmit buffer first gets written to and set high when the number of bytes written to the TOTALBYTES field of the FRAMES register have been sent on the bus. Additional devices must use GPIOs for their chip selects. It was reported to me that if there are two devices attached to this QSPI controller that the in-built chip select is set low while linux tries to access the device attached to the GPIO. This went undetected as the boards that connected multiple devices to the SPI controller all exclusively used GPIOs for chip selects, not relying on the built-in chip select at all. It turns out that this was because the built-in chip select, when controlled automagically, is set low when active and high when inactive, thereby ruling out its use for active-high devices or devices that need to transmit with the chip select disabled. Modify the driver so that it controls chip select directly, retaining the behaviour for mem_ops of setting the chip select active for the entire duration of the transfer in the exec_op callback. For regular transfers, implement the set_cs callback for the core to use. As part of this, the existing setup callback, mchp_coreqspi_setup_op(), is removed. Modifying the CLKIDLE field is not safe to do during operation when there are multiple devices, so this code is removed entirely. Setting the MASTER and ENABLE fields is something that can be done once at probe, it doesn't need to be re-run for each device. Instead the new setup callback sets the built-in chip select to its inactive state for active-low devices, as the reset value of the chip select in software controlled mode is low.
Title spi: microchip-core-qspi: control built-in cs manually
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-05-28T09:36:04.805Z

Reserved: 2026-05-13T15:03:33.101Z

Link: CVE-2026-46148

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Awaiting Analysis

Published: 2026-05-28T10:16:30.410

Modified: 2026-05-28T13:44:01.663

Link: CVE-2026-46148

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-05-28T13:15:20Z

Weaknesses