CVE-2026-10679 in Zephyr
Summary
by MITRE • 07/22/2026
The DesignWare SPI driver (drivers/spi/spi_dw.c) computed the SPI BAUDR clock divider as info->clock_frequency / config->frequency without validating config->frequency.
spi_transceive is a Zephyr __syscall and its verify handler (drivers/spi/spi_handlers.c) copies the caller-supplied spi_config from userspace without checking the frequency field, so a userspace thread that has been granted access to a DesignWare SPI device kernel object can pass frequency = 0 and trigger an unsigned integer divide-by-zero in spi_dw_configure().
On Cortex-M Mainline (SCB->CCR.DIV_0_TRP is set in z_arm_fault_init()) and on ARC (a dedicated __ev_div_zero vector) this raises a CPU exception, resulting in a kernel fault and local denial of service.
The fix rejects zero frequency and frequencies above clock_frequency / 2 (the DesignWare SSI databook minimum SCKDIV of 2) with -EINVAL. The defect affects all Zephyr releases up to and including v4.4.0; exploitation requires CONFIG_USERSPACE=y and an unprivileged thread already granted SPI driver permission. There is no memory-corruption or information-disclosure impact.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 07/22/2026
The DesignWare SPI driver in the Zephyr operating system contains a critical vulnerability stemming from inadequate input validation during clock configuration processing. This flaw exists within the spi_dw_configure function located in drivers/spi/spi_dw.c where the driver computes the SPI BAUDR clock divider using the formula info->clock_frequency / config->frequency without performing any validation on the config->frequency parameter. The vulnerability becomes particularly dangerous when combined with the kernel's syscall handling mechanism, specifically the spi_transceive function which operates as a Zephyr __syscall and processes user-supplied configuration data through its verify handler in drivers/spi/spi_handlers.c. This handler performs no validation of the frequency field within the spi_config structure before passing it to the kernel driver, creating a direct pathway for malicious input manipulation.
The operational impact of this vulnerability manifests through a classic divide-by-zero condition that occurs when a userspace thread with appropriate permissions attempts to configure an SPI device with a frequency value of zero. This scenario requires two specific conditions to be met: CONFIG_USERSPACE must be enabled in the kernel configuration and the unprivileged thread must have been granted access to the target DesignWare SPI device kernel object through proper permission assignment. When these conditions are satisfied, the malicious thread can submit a spi_config structure containing frequency = 0, which causes the unsigned integer division operation to trigger a CPU exception on ARM Cortex-M processors where SCB->CCR.DIV_0_TRP is enabled or on ARC processors with dedicated __ev_div_zero vector handling. The resulting kernel fault leads to immediate system termination and local denial of service, effectively compromising system availability.
The technical implementation of this vulnerability aligns with CWE-369: Divide by Zero, which specifically addresses the condition where a division operation uses a zero divisor without proper validation. This weakness creates a direct path for exploitation through the ATT&CK technique T1499.004: Network Denial of Service, as the vulnerability enables an attacker to cause system-wide service disruption. The fix implemented by the Zephyr development team addresses this issue by rejecting configuration values where frequency equals zero or exceeds clock_frequency / 2, which represents the minimum SCKDIV value specified in the DesignWare SSI databook and ensures proper hardware operation. This defensive programming approach prevents both the immediate divide-by-zero condition and maintains hardware compatibility requirements. The vulnerability affects all Zephyr releases up to and including version 4.4.0, making it a widespread concern for embedded systems deployed with these kernel versions. Importantly, while the vulnerability enables denial of service attacks, it does not provide opportunities for memory corruption or information disclosure, limiting its attack surface to availability concerns rather than confidentiality or integrity breaches. The mitigation strategy requires proper kernel configuration and access control enforcement to prevent unauthorized userspace threads from obtaining SPI device permissions, combined with the implemented validation logic that protects against malformed frequency values in the driver layer itself.