CVE-2026-46148
Received Received - Intake
SPI Chip Select Control Fix in Linux Kernel

Publication date: 2026-05-28

Last updated on: 2026-05-28

Assigner: kernel.org

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.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-05-28
Last Modified
2026-05-28
Generated
2026-05-28
AI Q&A
2026-05-28
EPSS Evaluated
N/A
NVD
EUVD
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
microchip coreqspi *
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability involves the Linux kernel's handling of the Microchip coreQSPI controller's chip select (CS) signal. The coreQSPI IP supports only a single chip select that is automatically controlled by hardware, which works well for one device but causes issues when multiple devices are attached.

When two devices are connected to the QSPI controller, the built-in chip select is set low (active) even when Linux tries to access a device that uses GPIO for chip select. This can cause conflicts because the hardware-controlled chip select does not support active-high devices or devices that need to transmit with chip select disabled.

The vulnerability was addressed by modifying the driver to manually control the chip select signal rather than relying on automatic hardware control. This ensures proper chip select behavior for multiple devices and removes unsafe operations during runtime.


How can this vulnerability impact me? :

This vulnerability can cause incorrect chip select signaling when multiple devices are connected to the Microchip coreQSPI controller. As a result, communication with SPI devices may fail or behave unpredictably.

Specifically, devices that rely on GPIO-controlled chip selects may be interfered with by the hardware-controlled chip select being active at the wrong times, potentially leading to data corruption, device malfunction, or communication errors.


What immediate steps should I take to mitigate this vulnerability?

The vulnerability is resolved by modifying the Linux kernel driver for the microchip-core-qspi to control the chip select (CS) manually rather than relying on the hardware automatic control.

Immediate mitigation steps include updating your Linux kernel to a version that includes this fix, which removes unsafe code related to CLKIDLE field modification during operation and implements direct control of the chip select line.

Ensure that your system does not rely on the built-in chip select for multiple devices attached to the QSPI controller, and verify that the driver uses GPIOs for chip selects where appropriate.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart