RT-Thread Version

v5.3.0

Affected area

Other / Not sure

Hardware/BSP vendor

Not applicable / Other

Architecture

Not applicable / Other

Board and hardware details

DM365 SPI

Develop Toolchain

Other

Describe the bug

RT-Thread DM365 SPI divides by an unchecked zero clock rate

Affected version

RT-Thread v5.3.0.

Describe the bug

davinci_spi_get_prescale() divides by the requested SPI frequency without rejecting zero. rt_spi_configure() copies max_hz into the device configuration and asks the bus to apply it.

An unchanged configuration returns before that call. A request that changes another field, such as data width 9, with max_hz == 0 does not. rt_spi_bus_configure() calls the driver only when this device currently owns the bus.

davinci_spi_setup_transfer() accepts data widths 2 through 16, copies cfg->max_hz, and calls the prescaler:

#define DIV_ROUND_UP(n, d) (((n) + (d) - 1) / (d))

ret = DIV_ROUND_UP(clk_get_rate(dspi->clk), max_speed_hz);

The prescaler clamps the result only after that division. A zero frequency is not turned into a default speed on this path.

Locations:

bsp/dm365/drivers/spi-davinci.c:35
bsp/dm365/drivers/spi-davinci.c:267
bsp/dm365/drivers/spi-davinci.c:272
bsp/dm365/drivers/spi-davinci.c:298
bsp/dm365/drivers/spi-davinci.c:313
bsp/dm365/drivers/spi-davinci.c:333
bsp/dm365/drivers/spi-davinci.c:788
components/drivers/spi/dev_spi_core.c:211
components/drivers/spi/dev_spi_core.c:277
components/drivers/spi/dev_spi_core.c:288

Threat model

The boundary is a caller of rt_spi_configure(device, cfg). This report does not treat a network peer or a byte on the SPI bus as the attacker. The value that reaches the division is cfg->max_hz. The caller also supplies cfg->mode and cfg->data_width. The clock rate returned for the controller is not caller input.

max_hz is a rt_uint32_t. Zero is the unsafe value. The core returns before calling the driver when mode, data width, and max_hz are all unchanged, so a request that only repeats the current configuration does not divide. A request that changes another field, such as setting data_width to 9 while leaving max_hz at 0, does reach the driver. data_width must also be 2 through 16 or the driver returns before the division. rt_spi_bus_configure() calls the driver only when this device currently owns the bus.

There is no shell command in this path. The entry is whatever product code can submit an SPI configuration: a trusted driver caller, or an untrusted service that forwards a frequency into rt_spi_configure().

Steps to reproduce

I have not reproduced this on DM365 hardware. The reduced check keeps the round-up macro and a positive clock.

#include <stdint.h>

#define DIV_ROUND_UP(n, d) (((n) + (d) - 1) / (d))

static int prescale(uint32_t max_hz)
{
    return DIV_ROUND_UP(48000000u, max_hz);
}

int main(void)
{
    return prescale(0);
}

Compile it with an undefined-behavior sanitizer, for example:

clang -fsanitize=undefined -g -O1 repro.c -o repro && ./repro

Returning an error when max_hz == 0, before the division, avoids the report. Positive rates such as 500 kHz complete the division.

Relevant log output

runtime error: division by zero
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior

Impact

A caller that can submit an SPI configuration for a DM365 SPI device, with a supported data width and a zero max_hz, reaches a division by zero in the driver when that device owns the bus. The reduced check shows the arithmetic fault. It does not show the processor exception on DM365 hardware, and this API is not by itself a network input.

Suggested fix

Reject zero before calling the prescaler, and keep a zero check inside the helper. If zero is intended to mean a default speed, resolve it to an explicit frequency first. Test a changed configuration whose max_hz is zero, plus the supported speed limits, before any transfer.

Other additional context

No response