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

Fermée Adaptée aux débutants
  • Quelque chose ne va pas ?
#11,950 1 commentaire 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

@r3wretrhy y travaille déjà.

Depuis le 30/10/2026.

  • #11957 par @r3wretrhy — ouverte

Évaluation

Difficulté
2/5
Temps estimé
1-3 heures
Accessibilité débutants
68/100
Type d'issue
Bug
Clarté
Clairement spécifiée
Activité
Active
Stack technique
c
Domaine
embedded-iot

Piste de recherche

Lisez bsp/dm365/drivers/spi-davinci.c autour de davinci_spi_get_prescale() et davinci_spi_setup_transfer(), puis suivez l’appel de configuration dans components/drivers/spi/dev_spi_core.c. Ajoutez un cas de configuration avec un débit nul et couvrez les limites de vitesse prises en charge avant tout transfert. Le travail est terminé lorsqu’une configuration modifiée avec max_hz == 0 est rejetée avant la division, tandis que les débits valides restent configurés avec succès.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

bug
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

Langage dominant
C
Étoiles
12.3k
Forks
5.5k
Merge moyen
4 j 9 h
PR mergées (30 j)
38

Préparer son environnement

Ouvrir dans Codespaces

Lance le conteneur de développement du projet dans votre navigateur, avec votre propre compte GitHub.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de RT-Thread/rt-thread

Toutes les issues de RT-Thread/rt-thread

Issues similaires

Plus d'issues C

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.