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

クローズ 初心者向け
  • 何か問題がありますか？
#11,950 コメント 1 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

@r3wretrhy がすでに取り組んでいます。

2026年10月30日 から。

  • #11957 @r3wretrhy による — オープン

評価

難易度
2/5
見積もり時間
1〜3時間
初心者へのやさしさ
68/100
issue の種類
バグ
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
c
領域
embedded-iot

調査の方向性

bsp/dm365/drivers/spi-davinci.c の davinci_spi_get_prescale() と davinci_spi_setup_transfer() の周辺を読み、続いて components/drivers/spi/dev_spi_core.c の設定呼び出しを追ってください。速度がゼロの設定ケースを追加し、転送を行う前にサポートされている速度の上限と下限を確認してください。変更後の設定で max_hz == 0 の場合に除算前に拒否され、有効な速度では引き続き正常に設定できれば完了です。

索引モデルが issue の本文から書いたものです。

説明

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

主要言語
C
スター
12.3k
フォーク
5.5k
平均マージ
4日 9時間
マージ済み PR（30日）
38

環境構築

Codespaces で開く

このプロジェクトの開発コンテナを、あなたの GitHub アカウントでブラウザ上に起動します。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

RT-Thread/rt-thread のほかの issue

RT-Thread/rt-thread の issue をすべて見る

似ている issue

C の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。