# CVE-2026-46148: spi: microchip-core-qspi: control built-in cs manually

> A Linux kernel driver bug causes incorrect chip select signaling when multiple devices are attached, potentially disrupting SPI communication.

- **Severity:** Medium 5.5 (`CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H`)
- **Exploited in the wild:** Not known
- **Login needed:** Any signed-in user
- **Attackable:** Local or same network only
- **Victim action needed:** Not needed
- **Fix available:** Yes
- **Published:** 28 May 2026
- **Updated:** 21 Oct 2026
- **Also known as:** BELL-CVE-2026-46148, DEBIAN-CVE-2026-46148, GHSA-v9m3-f9j3-xrv6, ROOT-OS-DEBIAN-12-CVE-2026-46148, ROOT-OS-DEBIAN-13-CVE-2026-46148, ROOT-OS-UBUNTU-2404-CVE-2026-46148, UBUNTU-CVE-2026-46148

## What is CVE-2026-46148?

CVE-2026-46148 is a medium-severity vulnerability in Linux kernel, published on 28 May 2026. It can only be exploited from the same machine or local network, with no action from the victim.

### Official description

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.

## Which versions are affected by CVE-2026-46148?

It affects 1 product.


Products: Linux kernel.

## How do I fix CVE-2026-46148?

Apply the vendor's patch.

## Is CVE-2026-46148 being exploited?

There is no known exploitation of CVE-2026-46148 in the wild and no public exploit code.

## Other vulnerabilities in Linux kernel

- [CVE-2026-53266](https://insights.sbomify.com/CVE-2026-53266/): Linux Kernel Out-of-Bounds Write (high 8.8, exploited in the wild)
- [CVE-2013-6282](https://insights.sbomify.com/CVE-2013-6282/): Linux Kernel Improper Input Validation (high 8.8, exploited in the wild)
- [CVE-2022-0185](https://insights.sbomify.com/CVE-2022-0185/): Linux Kernel Heap-Based Buffer Overflow (high 8.4, exploited in the wild)
- [CVE-2013-2094](https://insights.sbomify.com/CVE-2013-2094/): Linux Kernel Privilege Escalation (high 8.4, exploited in the wild)
- [CVE-2026-53362](https://insights.sbomify.com/CVE-2026-53362/): Linux Kernel Unspecified (high 7.8, exploited in the wild)

## Fix prompt for AI coding agents

```text
Check this codebase for CVE-2026-46148 and fix it if it is affected.

What it is: CVE-2026-46148 is a medium-severity vulnerability in Linux kernel, published on 28 May 2026. It can only be exploited from the same machine or local network, with no action from the victim.
Exploitation: There is no known exploitation of CVE-2026-46148 in the wild and no public exploit code.

Affected product: Linux kernel. No package-level version data is available, so check the vendor advisory linked from the reference page.

Task:
1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.
2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.
3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.
4. Run the tests and summarise what changed and why.
5. If nothing in the project is affected, say so and change nothing.

Reference: https://insights.sbomify.com/CVE-2026-46148/ (Markdown: https://insights.sbomify.com/CVE-2026-46148/index.md)
```

## Sources

- CVE record: https://www.cve.org/CVERecord?id=CVE-2026-46148
- NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-46148
- OSV: https://osv.dev/vulnerability/CVE-2026-46148

---
From sbomify Insights: https://insights.sbomify.com/CVE-2026-46148/
Summaries are generated and may contain mistakes; the official description above is the record.
