CVE-2026-46192

What it actually does

This is a local availability flaw in the Linux kernel Microchip Core QSPI controller driver. During emulated read-only dual/quad QSPI operations, the vulnerable driver may incorrectly attempt to transmit dummy data to generate clock cycles. Because QSPI dual/quad read modes do not behave like regular SPI with a separate MOSI line, that transmit attempt can corrupt or stall the transfer and leave the QSPI operation in a failed state. The practical impact is denial of service affecting systems that use the affected Microchip QSPI driver and expose a way for a local privileged or semi-privileged user to trigger the relevant flash/QSPI read path.

Why it matters to the business

Organizations running Linux on affected Microchip-based embedded, industrial, appliance, or IoT platforms may experience device instability, failed flash reads, service interruption, or complete unavailability if the vulnerable code path is triggered. The risk is lower than internet-exposed remote code execution because exploitation requires local access and there is no known public exploitation or CISA KEV listing, but the operational impact can still be significant for devices that rely on QSPI-attached flash for boot, firmware, configuration, or runtime data.

How an attack unfolds

An attacker first needs local access to a system using the affected Linux kernel driver for a Microchip Core QSPI controller. With sufficient permissions to interact with flash, MTD, SPI, firmware update, or device-management interfaces, the attacker triggers an emulated read-only dual/quad QSPI transaction. In vulnerable kernels, the driver attempts to transmit garbage data while the controller/core is expected to handle read clocking. This can brick the transfer or leave the QSPI controller in an inconsistent transmit/receive state, causing read failures and potentially disrupting services that depend on QSPI storage. There is no indication from the provided data that this vulnerability enables code execution, privilege escalation, data disclosure, ransomware activity, or active exploitation in the wild.

How to fix it

Upgrade to a Linux kernel version or vendor-provided kernel package that includes the fix for the Microchip Core QSPI driver behavior: the driver must not transmit dummy data during emulated read-only dual/quad operations. Because no exact fixed versions were provided, use the relevant distribution, appliance, board support package, or hardware vendor advisory to identify the patched kernel build. For embedded products, update the board support package and rebuild/redeploy firmware images containing the corrected kernel. If immediate patching is not possible, reduce exposure by restricting local shell access, limiting access to MTD/SPI/flash device nodes, disabling unneeded firmware or flash-management utilities, and ensuring only trusted administrative processes can initiate QSPI operations.

How to confirm the fix worked

Confirm that the running kernel contains the upstream or vendor backport for the Microchip Core QSPI driver change that removes driver-level dummy transmit behavior during emulated read-only dual/quad reads. Validate package status with the operating system or firmware vendor’s advisory and verify the active booted kernel, not just the installed package. On affected hardware, perform controlled QSPI dual/quad read tests and confirm transfers complete successfully without controller hangs, kernel warnings, I/O errors, or flash read failures. Also review device permissions for MTD/SPI/flash nodes to confirm untrusted local users cannot directly trigger the vulnerable path.

Typical attack path

1. Gain local access to a Linux system using the affected Microchip Core QSPI kernel driver.
2. Identify accessible interfaces that can trigger QSPI flash reads, such as MTD, SPI, firmware, boot storage, or device-management tooling.
3. Issue operations that cause emulated read-only dual/quad QSPI transfers.
4. Trigger the vulnerable driver behavior where dummy data is transmitted during a read operation.
5. Cause the QSPI transaction to fail or the controller/transfer state to become unusable, resulting in denial of service or device instability.

How to detect it

To determine whether the issue may have been triggered, review kernel and system logs for QSPI, SPI, MTD, flash, or storage read errors on affected hardware. Useful sources include dmesg, journalctl, /var/log/kern.log, /var/log/messages, embedded device console logs, firmware-management logs, and audit logs for access to MTD/SPI device nodes. Look for repeated transfer failures, timeouts, controller reset messages, read errors, or service crashes coinciding with local user sessions or commands that interact with flash devices. Since no public exploit pattern, malware behavior, or network indicator is provided, detection should focus on local activity and kernel/device error artifacts rather than network telemetry.

• microchip-core-qspi
• QSPI
• qspi
• spi transfer failed
• SPI transfer failed
• transfer timed out
• read-only dual
• read-only quad
• mtd read error
• MTD read error
• flash read error
• /dev/mtd
• /dev/mtd0
• /dev/spidev
• /var/log/kern.log
• /var/log/messages

What your security team should do

• Prioritize remediation for embedded, industrial, appliance, or production devices that use Microchip Core QSPI storage and where local users, maintenance accounts, containers, or management services can interact with flash interfaces.
• Obtain patched kernels or firmware images from the Linux distribution, hardware vendor, or board support package maintainer and schedule deployment through the normal kernel/firmware update process.
• Inventory systems for Microchip Core QSPI controller usage and exposed MTD/SPI/flash device nodes.
• Restrict access to flash-management interfaces and device nodes to trusted administrative users and services only.
• Monitor for kernel logs showing QSPI, SPI, MTD, or flash read failures, especially following local user activity or firmware-management operations.
• Treat repeated unexplained QSPI transfer failures on unpatched systems as a potential availability attack or misuse until ruled out.
• Because EPSS is very low, exploit maturity is listed as none, and the issue is not in CISA KEV, prioritize based on operational criticality and hardware exposure rather than broad internet-scale exploitation risk.