Skip to main content

Linux Kernel EUVDEUVD-2026-32819

| CVE-2026-46192 MEDIUM
2026-05-28 416baaa9-dc9f-4396-8d5f-8c081fb06d67 GHSA-fg62-m4w4-qg3p
Linux Information Disclosure Red Hat Suse
5.5
CVSS 3.1 · NVD
Share

Severity by source

NVD PRIMARY
5.5 MEDIUM
AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
vuln.today AI
5.5 MEDIUM

Local vector and low privileges required to issue QSPI I/O; no confidentiality or integrity impact, only availability loss from bricked transfer.

3.1 AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
4.0 AV:L/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
SUSE
MEDIUM
qualitative

Primary rating from NVD.

CVSS VectorNVD

CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Attack Vector
Local
Attack Complexity
Low
Privileges Required
Low
User Interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
None
Availability
High

Lifecycle Timeline

5
Analysis Generated
Jun 11, 2026 - 03:23 vuln.today
CVSS changed
Jun 11, 2026 - 03:22 NVD
5.5 (MEDIUM)
Patch available
May 28, 2026 - 12:01 EUVD
CVE Published
May 28, 2026 - 10:16 nvd
UNKNOWN (no severity yet)
CVE Published
May 28, 2026 - 10:16 nvd
MEDIUM 5.5

DescriptionNVD

In the Linux kernel, the following vulnerability has been resolved:

spi: microchip-core-qspi: don't attempt to transmit during emulated read-only dual/quad operations

The core will deal with reads by creating clock cycles itself, there's no need to generate clock cycles by transmitting garbage data at the driver level. Further, transmitting garbage data just bricks the transfer since QSPI doesn't have a dedicated master-out line like MOSI in regular SPI. I'm not entirely sure if the transfer is bricked because of the garbage data being transmitted on the bus or because the core loses track of whether it is supposed to be sending or receiving data.

AnalysisAI

Denial of service in the Linux kernel's Microchip Core QSPI driver corrupts SPI transfers on systems using this controller. The spi-microchip-core-qspi driver incorrectly attempts to transmit garbage data during emulated read-only dual/quad SPI operations - a protocol violation, since QSPI lacks a dedicated MOSI line and the core hardware is expected to generate read clock cycles autonomously. The result is a bricked (permanently failed) SPI transfer, causing availability loss for any kernel component or userspace process depending on that SPI bus. No public exploit exists and EPSS probability is 0.02%, consistent with a hardware-specific, locally-triggered driver defect.

Technical ContextAI

The vulnerability resides in the spi-microchip-core-qspi Linux kernel driver, which manages the Microchip PolarFire SoC QSPI (Quad SPI flash) controller. QSPI extends standard SPI by multiplexing four data lines (IO0-IO3) for higher throughput; crucially, in dual/quad read mode there is no dedicated master-out (MOSI) line - all data lines are used for device-to-host data. The hardware core handles read clock generation internally during these emulated read-only operations. The driver incorrectly issues a transmit operation alongside the read, sending undefined (garbage) data onto the shared bus. This either corrupts the in-flight data or confuses the controller state machine regarding whether it should be sending or receiving. Affected CPE: cpe:2.3:o:linux:linux_kernel across versions from commit 8f9cf02c8852837923f1cdacfcc92e138513325c up to the fix commits. No CWE is assigned by NVD, but the root cause class is an incorrect logical flow control (analogous to CWE-670: Always-Incorrect Control Flow Implementation) - the driver takes a transmit code path that should be suppressed for read-only QSPI operations.

RemediationAI

The primary fix is a kernel upgrade: apply Linux 6.18.30, 7.0.7, or 7.1-rc3 (or later), depending on the tracked stable series. The upstream fixes are available at three stable-tree commits: https://git.kernel.org/stable/c/eb56deaabf127e8985fc91fa6c97bf8a3b062844, https://git.kernel.org/stable/c/67184f361ab4d9fac6d2b8d5fed6649d496038a4, and https://git.kernel.org/stable/c/ec9d0ddbde6003c303fa5e1d5cd48952852984d8. Downstream Linux distributions (e.g., Yocto-based BSPs for PolarFire SoC) should backport these commits if they track kernel versions older than the fix points. As a compensating control where a kernel update is not immediately feasible, operators can restrict access to the QSPI device node (e.g., /dev/spidevX.Y or mtdX) to privileged processes only via udev rules or file permissions, which raises the exploitation bar from PR:L to PR:H; the trade-off is that any userspace SPI flash tooling will also lose access. Blacklisting the spi-microchip-core-qspi module is not a viable workaround on systems that depend on the QSPI bus for flash storage.

Same technique Information Disclosure

View all
CVE-2013-2251 CRITICAL POC
9.8
CVE-2017-5638 CRITICAL POC
9.8
CVE-2025-24813 CRITICAL POC
9.8
CVE-2015-1701 HIGH POC
7.8
CVE-2017-0147 HIGH POC
7.5
CVE-2014-6324 HIGH POC
8.8
CVE-2023-7028 CRITICAL POC
10.0
CVE-2017-0213 HIGH POC
7.3

Vendor StatusVendor

SUSE

Severity: Moderate
Product Status
openSUSE Tumbleweed Fixed
SUSE Linux Enterprise Desktop 15 SP7 Not-Affected
SUSE Linux Enterprise Desktop 15 SP7 Not-Affected
SUSE Linux Enterprise High Availability Extension 15 SP7 Not-Affected
SUSE Linux Enterprise High Availability Extension 15 SP7 Not-Affected

Share

EUVD-2026-32819 vulnerability details – vuln.today
Back

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy