Linux Kernel CVE-2026-46148

Four simultaneous conditions are required: (1) the system runs a Linux kernel between commit 8596124c4c1bc7561454cee0463c16eca70b5d25 and the fix commits - specifically pre-6.18.30, pre-7.0.7, or pre-7.1-rc3; (2) a Microchip coreQSPI IP controller is present in the hardware and bound to the affected driver; (3) at least two SPI devices are wired to the same coreQSPI controller - one relying on the built-in hardware CS and one using a GPIO CS; and (4) a local process with SPI device access (PR:L) initiates a transaction to the GPIO-CS device. The flaw does NOT trigger on single-device QSPI configurations or on systems where all devices use exclusively GPIO chip selects - the latter was noted as common in boards with multiple devices, which is why this bug went undetected for an extended period. Physical hardware topology is the primary limiting factor; this cannot be exploited remotely or against general-purpose Linux servers.

The NVD CVSS 3.1 vector AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H (5.5 Medium) is broadly accurate: exploitation is local, requires low-privilege access, and produces only availability impact with no confidentiality or integrity consequences. EPSS at 0.02% (4th percentile) strongly corroborates that this is not a target of opportunistic exploitation - it is a driver correctness bug in a niche embedded SPI controller. The absence of a KEV listing and any public proof-of-concept code further reduces real-world urgency. Importantly, the EUVD 'Information Disclosure' tag is inconsistent with the CVSS C:N metric and the description's content; this tag appears to be a classification error and should not be treated as a signal of data exfiltration risk. The highest realistic risk is incidental rather than adversarial: a local process initiating SPI I/O on a system with the affected hardware topology could destabilize the SPI bus and cause peripheral or kernel driver failure. Priority should be low except for operators of Microchip PolarFire SoC systems with multi-device QSPI topologies running unpatched kernels.

A local low-privilege user or process on an embedded Linux system (such as a Microchip PolarFire SoC board) running an unpatched kernel initiates an SPI transaction to a device connected via GPIO chip select. The coreQSPI hardware concurrently asserts the built-in CS line, placing an unintended active signal on a second SPI device sharing the same bus, causing that device's driver to receive corrupted or unexpected data - potentially triggering a kernel oops, SPI controller lockup, or peripheral reset that renders the system partially or fully unavailable. No public exploit code exists; the trigger is effectively any legitimate SPI transaction on the affected hardware.