CVE-2026-46148

What it actually does

This is a Linux kernel driver flaw in the Microchip coreQSPI SPI controller chip-select handling. On systems with multiple devices attached to the same QSPI controller, the controller’s built-in chip select can be asserted while Linux is attempting to access a different device that uses a GPIO-controlled chip select. That can cause the wrong peripheral to be selected during transfers, creating bus contention, failed SPI/QSPI transactions, peripheral lockups, or loss of access to attached storage or flash devices. The assigned impact is availability-focused: exploitation requires local access with the ability to trigger affected device operations, and there is no indicated confidentiality impact.

Why it matters to the business

Affected embedded, industrial, appliance, or server platforms using the Linux kernel with Microchip coreQSPI hardware may experience device hangs, flash/storage access failures, degraded service, or outages if local users or workloads can trigger the vulnerable SPI/QSPI paths. The issue is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, has very low EPSS, and has no reported public exploit maturity, so broad internet-scale exploitation is unlikely; however, affected operational technology or embedded systems may have high business impact if QSPI-connected devices are required for boot, configuration, firmware storage, or runtime operation.

How an attack unfolds

An attacker first needs local access to a Linux system running an affected kernel on hardware that uses the Microchip coreQSPI controller with multiple attached SPI/QSPI devices, especially where at least one device uses the controller’s built-in chip select and another uses GPIO chip select. The attacker then triggers repeated or carefully timed access to the device behind the GPIO-controlled chip select, for example through an exposed character device, MTD interface, flash operation, or application path that causes SPI/QSPI transfers. Because the driver may allow the built-in chip select to become active during access to the other device, the wrong device can be selected on the bus. This can corrupt the expected transaction, cause controller or peripheral errors, and lead to denial of service conditions such as device lockup, failed reads/writes, kernel-visible I/O errors, or loss of availability of dependent services.

How to fix it

Apply a Linux kernel update from the operating system, board-support-package, or device vendor that includes the corrected Microchip coreQSPI driver behavior, where the driver manually controls the built-in chip select and avoids unsafe per-device manipulation during operation. No exact fixed package versions were provided in the input, so use the vendor advisory, stable kernel release notes, or downstream BSP changelog to identify the first fixed build for each maintained kernel branch. Where immediate patching is not possible, reduce exposure by restricting local user access to SPI/QSPI, MTD, flash, and spidev interfaces; disabling unnecessary device nodes; limiting workloads that can trigger raw peripheral transfers; and reviewing hardware/device-tree configurations to avoid unsafe mixed chip-select arrangements where feasible. For embedded products, incorporate the fix into firmware images and regression-test all QSPI-attached devices before deployment.

How to confirm the fix worked

Confirm remediation by verifying the running kernel or vendor BSP contains the Microchip coreQSPI driver fix for manual built-in chip-select control. Review the kernel source or packaged changelog for changes to the microchip-core-qspi driver that add direct chip-select handling and remove unsafe setup behavior. On affected hardware, validate with functional tests that transfers to a GPIO-chip-select device do not assert the built-in chip select; where possible, use a logic analyzer or oscilloscope to observe chip-select lines during concurrent or repeated SPI/QSPI operations. Confirm that dmesg and system logs no longer show SPI controller errors, QSPI timeouts, MTD read/write failures, or peripheral reset events during stress testing. Also verify that unprivileged users cannot access raw SPI/QSPI or flash interfaces unless explicitly required.

Typical attack path

1. Identify a local system running an affected Linux kernel on Microchip coreQSPI hardware.
2. Confirm that the QSPI bus has multiple attached devices with mixed built-in and GPIO chip-select usage.
3. Obtain local low-privileged access or access to an application/API that can trigger SPI, QSPI, MTD, flash, or spidev operations.
4. Generate repeated or concurrent transfers to a GPIO-selected device on the affected controller.
5. Trigger unintended assertion of the built-in chip select during those transfers.
6. Cause bus contention, failed transactions, peripheral errors, or device lockup resulting in service degradation or denial of service.

How to detect it

There are no public, CVE-specific exploit artifacts or unique network indicators for this issue. Detection should focus on evidence of abnormal local triggering of SPI/QSPI or flash operations followed by hardware communication failures. Review kernel logs, system journals, audit logs, device access logs, and application logs for bursts of access to SPI, QSPI, MTD, flash, or spidev interfaces followed by controller timeouts, failed transfers, I/O errors, device resets, filesystem read/write failures, or service crashes. On systems with auditd or equivalent telemetry, look for untrusted users or unexpected processes opening raw peripheral device nodes or invoking utilities that interact with flash or SPI devices. Correlate suspicious local activity with dmesg entries from the Microchip coreQSPI driver, SPI subsystem, MTD subsystem, or affected peripheral drivers. For high-assurance investigations, capture bus-level traces from chip-select lines to determine whether the built-in chip select was asserted during access to a GPIO-selected device.

What your security team should do

• Prioritize inventory of Linux-based products and appliances using Microchip coreQSPI hardware, especially embedded or operational systems where QSPI-attached devices are critical for boot, firmware, storage, or control functions.
• Patch affected kernels or vendor BSPs during the next maintenance window; accelerate remediation for systems where local users, containers, plugins, or exposed management functions can trigger SPI/QSPI or flash operations.
• Harden local access by restricting permissions on spidev, MTD, flash, and other peripheral device nodes to only trusted administrative processes.
• Review device-tree and board configurations for multiple devices on the same Microchip coreQSPI controller and identify mixed built-in/GPIO chip-select designs that are most likely to be affected.
• Add monitoring for kernel-reported SPI/QSPI, MTD, flash, and storage errors on affected platforms until patched.
• Because the issue is not KEV-listed, not associated with ransomware, and has very low EPSS, treat it as targeted/local-risk rather than broad internet-facing emergency risk, unless the affected device performs safety-critical or high-availability functions.