Bug 2400633 (CVE-2025-39921) - CVE-2025-39921 kernel: spi: microchip-core-qspi: stop checking viability of op->max_freq in supports_op callback
Summary: CVE-2025-39921 kernel: spi: microchip-core-qspi: stop checking viability of o...
Keywords:
Status: NEW
Alias: CVE-2025-39921
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Product Security DevOps Team
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2025-10-01 09:01 UTC by OSIDB Bzimport
Modified: 2025-11-26 11:33 UTC (History)
0 users

Fixed In Version:
Clone Of:
Environment:
Last Closed:
Embargoed:


Attachments (Terms of Use)

Description OSIDB Bzimport 2025-10-01 09:01:56 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.