CVE-2025-40014 Overview
CVE-2025-40014 is an out-of-bounds stack access vulnerability in the Linux kernel's AMD Serial Peripheral Interface (SPI) driver. The flaw resides in the amd_set_spi_freq() function within drivers/spi/spi-amd.c. When a caller supplies a speed_hz value lower than AMD_SPI_MIN_HZ, the function iterates past the end of the amd_spi_freq array without an early exit. The loop index i advances beyond the array bounds, producing out-of-bounds stack access. The issue was surfaced by objtool as a control-flow warning showing the function falling through to amd_spi_set_opcode(). The vulnerability is tracked under [CWE-129: Improper Validation of Array Index].
Critical Impact
A local, low-privileged actor interacting with the AMD SPI driver can trigger out-of-bounds stack access, threatening kernel confidentiality, integrity, and availability.
Affected Products
- Linux Kernel (upstream linux_kernel) versions prior to the fixes referenced in the stable tree
- Systems using the spi-amd driver on AMD platforms exposing the SPI controller
- Downstream distributions shipping kernels that include the pre-patch amd_set_spi_freq() implementation
Discovery Timeline
- 2025-04-18 - CVE-2025-40014 published to the National Vulnerability Database
- 2026-06-17 - Last updated in NVD database
Technical Details for CVE-2025-40014
Vulnerability Analysis
The amd_set_spi_freq() function selects an operating frequency from the static amd_spi_freq array based on the requested speed_hz. The loop compares each entry against the requested speed and breaks when a suitable value is found. When speed_hz is smaller than the minimum supported frequency (AMD_SPI_MIN_HZ), the loop never satisfies its break condition. Loop counter i continues past the last valid index and reads memory beyond the array on the kernel stack.
The issue was detected during a build with an Undefined Behavior Sanitizer (UBSAN) kernel. objtool emitted the warning: drivers/spi/spi-amd.o: error: objtool: amd_set_spi_freq() falls through to next function amd_spi_set_opcode(). This confirms the compiler generated code that spills control into an adjacent function due to the missing loop termination.
A local attacker with sufficient access to invoke the SPI transfer path can influence the frequency parameter, driving the loop out of bounds. The impact reaches kernel-space memory, which is why availability, integrity, and confidentiality are all affected.
Root Cause
The root cause is missing bounds enforcement in the frequency-selection loop. The code assumed a valid match would always be found within amd_spi_freq, so the loop lacked a terminating condition tied to the array length. When callers passed a speed below the minimum supported value, this assumption failed and index i walked past the array.
Attack Vector
The attack vector is local and requires low privileges but no user interaction. An unprivileged process able to reach the SPI driver, such as through a user-facing SPI device node or an ioctl path that ultimately calls amd_set_spi_freq() with an attacker-controlled speed, can trigger the out-of-bounds condition. The consequence can range from kernel information disclosure to kernel memory corruption depending on stack layout and following instructions.
No public proof-of-concept exploit is available and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog. Refer to the upstream fix commits 76e51db43fe4 and 7f2c746e09a3 for the exact code changes.
Detection Methods for CVE-2025-40014
Indicators of Compromise
- Kernel log entries referencing spi-amd, amd_set_spi_freq, or unexpected control-flow into amd_spi_set_opcode()
- UBSAN or KASAN reports flagging out-of-bounds access in drivers/spi/spi-amd.c
- Unexpected kernel oopses or panics on AMD platforms shortly after userland processes access SPI device nodes
Detection Strategies
- Build test kernels with CONFIG_UBSAN and CONFIG_KASAN enabled to surface the out-of-bounds access at runtime
- Enable objtool warnings during kernel builds and treat fall-through diagnostics for amd_set_spi_freq() as evidence of an unpatched driver
- Inventory hosts and query package versions to identify kernels shipped before the two upstream fix commits
Monitoring Recommendations
- Forward dmesg and journald kernel logs to a central store and alert on spi-amd faults, stack traces, or sanitizer reports
- Track kernel package versions across the fleet and flag any AMD system running a kernel without the referenced stable-tree patches
- Monitor for unprivileged processes opening /dev/spidev* nodes on systems where SPI userspace access is unexpected
How to Mitigate CVE-2025-40014
Immediate Actions Required
- Apply the upstream stable kernel updates that include commits 76e51db43fe4 and 7f2c746e09a3
- Track your Linux distribution's security advisories and install vendor-provided kernel packages once available
- Restrict access to SPI device nodes to trusted, privileged users on AMD systems until the patched kernel is deployed
Patch Information
The fix modifies the loop in amd_set_spi_freq() so it stops at the last entry in amd_spi_freq. This clamps any speed_hz value below AMD_SPI_MIN_HZ up to the minimum supported frequency and prevents index i from exceeding the array bounds. See the kernel git commit 76e51db43fe4 and the companion commit 7f2c746e09a3 for the exact code changes.
Workarounds
- Unload the spi-amd kernel module on systems that do not require AMD SPI functionality: modprobe -r spi_amd
- Blocklist the driver via /etc/modprobe.d/ on AMD systems where SPI access is not needed for the workload
- Tighten permissions on /dev/spidev* device nodes so only trusted service accounts can reach the vulnerable code path
# Configuration example: prevent the vulnerable driver from loading
echo 'blacklist spi_amd' | sudo tee /etc/modprobe.d/blacklist-spi-amd.conf
sudo modprobe -r spi_amd 2>/dev/null || true
sudo update-initramfs -u
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

