SEC.co
Emergency
MEDIUM 5.5

CVE-2026-46148

A flaw in the Linux kernel's Microchip CoreQSPI SPI controller driver causes incorrect chip select (CS) line management when multiple SPI devices are connected. The hardware's built-in CS is automatically controlled by design, but this automatic behavior conflicts with proper operation when GPIO-based chip selects are also in use. The driver was modified to manually control the CS line instead, allowing correct behavior for both active-low and active-high devices, and preventing the built-in CS from being asserted while other GPIO-controlled devices are being accessed.

Source data · NVD / CISA · public domain

CVSS
3.1 · 5.5 MEDIUM · CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Weaknesses (CWE)
—
Affected products
3 configuration(s)
Published / Modified
2026-05-28 / 2026-06-17

NVD description (verbatim)

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.

3 reference(s) · View on NVD →

SEC.co analysis · AI-assisted, reviewed against source

Technical summary

The Microchip CoreQSPI IP contains a single built-in chip select that is automatically managed by hardware—driven low when data is written to the transmit buffer and driven high when the byte count specified in the FRAMES register's TOTALBYTES field has been transmitted. The vulnerability occurs in the Linux kernel driver (spi: microchip-core-qspi) when multiple SPI devices share the same controller: the built-in CS can be driven low while the kernel attempts to communicate with a GPIO-controlled device, causing bus contention and protocol violations. The resolution involves switching from automatic CS control to manual software control via a new set_cs callback, while preserving the original behavior for memory operations by keeping CS asserted throughout the transfer. The fix also removes unsafe runtime modification of the CLKIDLE field and defers MASTER and ENABLE register setup to probe time.

Business impact

This vulnerability primarily affects embedded systems and IoT devices using Microchip CoreQSPI controllers with multi-device SPI buses. In production systems, incorrect CS line timing can cause data corruption, device communication failures, or system instability when SPI peripherals (sensors, storage, wireless modules) are accessed simultaneously. Organizations deploying such hardware may experience device timeouts, lost sensor readings, or interrupted storage access, leading to operational disruptions and potential data loss. The impact is most severe in systems that mix hardware-managed and GPIO-based chip selects without realizing the conflict.

Affected systems

The vulnerability affects the Linux kernel's CoreQSPI driver (spi: microchip-core-qspi), specifically on systems using Microchip's CoreQSPI IP with multiple SPI devices. Affected platforms include embedded Linux systems, development boards, and production devices based on Microchip FPGAs or SoCs that integrate the CoreQSPI controller and rely on the kernel's SPI subsystem. Systems using only GPIO-based chip selects were largely unaffected in practice, as they did not rely on the built-in CS; systems mixing built-in and GPIO-based CS experienced the issue. The vulnerability is present in kernel versions prior to the fix commit.

Exploitability

Exploitability is low. This is a driver behavioral flaw rather than a memory safety or authentication vulnerability. An attacker cannot remotely trigger the condition; it requires local access to a system with the affected kernel and a multi-device SPI configuration. The flaw manifests as a functional bug—race conditions and CS line conflicts—rather than as a direct avenue for privilege escalation or code execution. However, an unprivileged user with access to SPI device interfaces could potentially trigger SPI communication errors or denial of service by accessing multiple SPI devices concurrently, though this is more a system misconfiguration than an exploitable vulnerability in the traditional sense.

Remediation

Update the Linux kernel to a version incorporating the fix for CVE-2026-46148. Verify the specific kernel version against your vendor's advisory (e.g., Red Hat, Canonical, or your device manufacturer). The fix transitions the CoreQSPI driver to manual chip select control, removing automatic hardware management. No configuration changes are required post-patch, though systems should be tested to confirm that all SPI devices (especially those using GPIO-based chip selects) function correctly after the update. For systems unable to patch immediately, avoid concurrent access to multiple SPI devices on the same CoreQSPI bus, or isolate devices to separate SPI controllers.

Patch guidance

Apply the kernel update provided by your Linux distribution or device vendor. The fix is identified by commit hash and description in the Linux kernel repository. Distributions such as Red Hat, Canonical (Ubuntu), and Debian typically backport the fix to stable kernel branches; check your vendor's security advisory for specific version numbers. For custom kernels, apply the upstream patch directly. Test thoroughly on staging hardware with your full SPI device configuration before production deployment, particularly if you use mixed CS types (built-in and GPIO). Verify that memory-mapped SPI operations (mem_ops) and regular SPI transfers both function correctly post-patch.

Detection guidance

Monitor system logs and dmesg for SPI driver errors, timeouts, or device communication failures, particularly when multiple SPI devices are in use. Use tools like `spidev_test` or vendor-supplied SPI diagnostic utilities to validate communication with each attached device under load. In production, track device error rates and unexpected sensor data gaps that might indicate CS line conflicts. Kernel-level tracing (ftrace, eBPF) can capture CS line state transitions and correlate them with SPI transfers if you suspect the vulnerability is affecting your system. Check your kernel version and confirm it includes the fix.

Why prioritize this

CVE-2026-46148 should be prioritized for systems using Microchip CoreQSPI with multiple SPI devices, especially in edge computing, industrial IoT, or embedded applications where sensor and storage reliability are critical. The CVSS score of 5.5 (Medium) reflects local-only exploitability and high availability impact. While not immediately exploitable remotely, the functional impact—silent data corruption or device failures—can disrupt operations and is harder to diagnose than a clear crash. Prioritize based on your device inventory: high priority for production deployments with mixed SPI configurations, lower priority for systems using only GPIO-based chip selects.

Risk score, explained

CVSS 3.1 score of 5.5 (Medium severity) is driven by: Attack Vector Local (no remote trigger), Attack Complexity Low (bug occurs reliably in affected configurations), Privileges Required Low (kernel driver flaw; user-level SPI access can trigger it), User Interaction None, and high impact on Availability (system instability, device failures). Confidentiality and Integrity are not directly impacted by the CS line bug itself. The score appropriately reflects a functional correctness issue that degrades system reliability rather than enabling arbitrary code execution or data theft.

Frequently asked questions

Will this vulnerability affect my system if I use only GPIO-based chip selects?

No. The vulnerability manifests only when the Microchip CoreQSPI's built-in CS and GPIO-based CS lines are both in active use on the same controller. If your design uses GPIOs exclusively for all chip selects, the automatic hardware CS behavior is irrelevant and the bug does not surface.

What symptoms would indicate this vulnerability is affecting my system?

Look for intermittent SPI communication failures, timeouts, data corruption, or unresponsive SPI peripherals when multiple devices are accessed. If you see CS line asserted at the wrong time in logic analyzer traces, or devices report errors when another device is active on the same bus, the vulnerability is likely active.

Do I need to reconfigure anything after patching?

No. The patch changes driver behavior transparently. After updating the kernel and rebooting, manual CS control will be active automatically. Simply verify that your SPI devices function correctly in testing before deploying to production.

How does this affect active-high chip select devices?

Previously, the automatic hardware CS was always driven low when active and high when inactive, making it unsuitable for active-high devices. The manual control in the fix allows the driver to respect device-specific CS polarity, so active-high devices can now work correctly with the built-in CS.

This analysis is provided for informational purposes and is based on the published CVE record and kernel commit documentation. Specific patch version numbers, release dates, and vendor-specific guidance should be verified against your Linux distribution's security advisory and the Linux kernel project's official repository. SEC.co does not provide legal advice regarding vulnerability management or compliance. Organizations should conduct their own risk assessment based on their specific hardware configurations and deployment scenarios. Always test patches in a staging environment before production deployment. Source: NVD (public-domain), retrieved 2026-07-07. Analysis generated by SEC.co (claude-haiku-4-5).

Affected vendors

linux

Related vulnerabilities