Skip to main content
VulnerabilityPublished Updated

CVE-2025-39921: Linux kernel · spi: microchip-core-qspi: stop checking viability of op->max_freq in supports_op

Affects Linux kernelSource CVE Database V5

0

Not known to be exploited · CVSS 5.5 Medium · fixed in ac8a13f35d5b8996582b3f97b924838a5c570c18 : update Linux kernel when convenient.

Data as of 26 Oct 2026, 14:18 UTC

CVSS 3.1 base score
5.5Medium
How severe the flaw is on the 0–10 CVSS scale.
EPSS
0.1% chance of exploitation in 30 days – higher than 8% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
CISA SSVC
Exploitation
No evidence of active exploitation and no public proof of concept
Automatable
Attackers cannot reliably automate steps 1–4 of the kill chain
Technical impact
Limited control over the software or limited information exposure

CISA SSVC assessment, 2026-01-14.

Patch
Available – fixed in ac8a13f35d5b8996582b3f97b924838a5c570c18, 89e7353f522f5cf70cb48c01ce2dcdcb275b8022, 4ad071e3d57967f7ab483aed0687468bc1d9e9ce
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 1 Oct 2025

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponised: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq Mirage: no evidence on record.

    No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.

What to do

Upgrade Linux kernel to ac8a13f35d5b8996582b3f97b924838a5c570c18, 89e7353f522f5cf70cb48c01ce2dcdcb275b8022 or 4ad071e3d57967f7ab483aed0687468bc1d9e9ce.

Affected software

ProductAffectedFixed in
LinuxLinuxAffected
  • ≥ 13529647743d906ed3cf991f1d77727e7ff1fb6f, < ac8a13f35d5b8996582b3f97b924838a5c570c18
Fixed in
  • ac8a13f35d5b8996582b3f97b924838a5c570c18
LinuxLinuxAffected
  • ≥ 13529647743d906ed3cf991f1d77727e7ff1fb6f, < 89e7353f522f5cf70cb48c01ce2dcdcb275b8022
Fixed in
  • 89e7353f522f5cf70cb48c01ce2dcdcb275b8022
LinuxLinuxAffected
  • ≥ d29f749d5202605dbb7480791e6841487d8afb77, < 4ad071e3d57967f7ab483aed0687468bc1d9e9ce
Fixed in
  • 4ad071e3d57967f7ab483aed0687468bc1d9e9ce
LinuxLinuxAffected
  • =6.14
Fixed in–

Description

In the Linux kernel, the following vulnerability has been resolved: spi: microchip-core-qspi: stop checking viability of op->max_freq in supports_op callback In commit 13529647743d9 ("spi: microchip-core-qspi: Support per spi-mem operation frequency switches") the logic for checking the viability of op->max_freq in mchp_coreqspi_setup_clock() was copied into mchp_coreqspi_supports_op(). Unfortunately, op->max_freq is not valid when this function is called during probe but is instead zero. Accordingly, baud_rate_val is calculated to be INT_MAX due to division by zero, causing probe of the attached memory device to fail. Seemingly spi-microchip-core-qspi was the only driver that had such a modification made to its supports_op callback when the per_op_freq capability was added, so just remove it to restore prior functionality.

References

Community reviews

Loading reviews…