調査期間：2026-11-03 08:00 ~ 2026-11-04 08:00（北京時間、24時間）

情報源：RT-Thread 公式ニュースインターフェースと公式サイトニュース一覧、GitHub メインリポジトリの commits / PR / Issue / releases / tags、RT-Thread org の重点リポジトリ13件の Atom コミットフィード、GitHub リポジトリ検索（rt-thread キーワードと topic:rt-thread）、Google News の中国語・英語6組のクエリ（プロキシ経由）、HN Algolia、電子工程専輯 RT-Thread 公式コラム、世界インターネット大会公式サイトと網信辦の通稿、鳳凰網ビジネスニュース、club.rt-thread.org フォーラム（本期も引き続きサイト WAF の制限を受ける）

本期インデックス

    1. カーネルとバージョン動向
      • getaddrinfo のネストしたユーザーポインタ強化がマージ：一度のスナップショットが階層検証に取って代わる（11-03）
      • DM365 の SPI 分周器でゼロ除算、max_hz に 0 を渡すと発生（11-03）
      • mailbox テストケースが2回目の実行で必ず失敗：4つの完了フラグが一度もクリアされない（11-03）
      • マクロのコメントは行末か上方か：コーディング規範に判定基準を一節追加（11-03）
    1. セキュリティフォローとマージ待ちキュー
      • timerfd が任意の fd を受け入れる：2つのシステムコールでカーネル PC 制御に到達（11-04）
      • POSIX timer の id が未検証、RT-Smart 上でコンソールデバイスを書き換え可能（11-03）
      • ブロックデバイスパーティション ioctl の任意カーネル書き込みに提案が届く（11-03）
      • キュー：pipe パッチはまだ修正中、5件の旧課題が引き続き残る（11-03）
    1. 公式・コミュニティ活動
      • 烏鎮「新光」：AIOS 基盤が選出、語られたのは仮想化ハイブリッドデプロイ（11-02 ~ 11-03）
      • オープンソース AIOS 連盟が小型身体性知能を討論、RT-Thread は3類の Agent 方案を講演（11-03）
      • 公式ニュースインターフェースは依然6月で停止、リリースの出口は引き続きメディアコラム（11-04）
    1. エコシステムとベンダー適合
      • 野火 HPM6750 BTB の Studio BSP が GitHub に公開、インストール手順を5ステップで記載（11-04）
      • 新唐 N9H30 のコミュニティ BSP：HMI プラットフォームの ARM926EJ-S の古参（11-03）
      • デュアル MCU 消毒装置：M7 が運動、M3 が噴霧を担当、両方とも RT-Thread を実行（11-03）
    1. 産業応用
      • RV32IM デュアルイシュー FPGA CPU が RT-Thread Nano を CoreMark 検証チェーンに接続（11-03）
    1. 本期のトレンドとまとめ
      • トレンド：セキュリティ側は報告から提案へ、テスト側はリストからコードへ
      • 限界と重複排除の説明

1. カーネルとバージョン動向

1.1 getaddrinfo のネストしたユーザーポインタ強化がマージ：一度のスナップショットが階層検証に取って代わる（11-03）

日付：2026-11-03 09:04（マージ時刻）　出典：提案 #11977

前回報じたメンテナによる作り直しが、調査期間の冒頭にマージされた。57行追加、17行削除、ネットワークシステムコールディレクトリ下の syscall_netdb.c 1ファイルのみを変更。

元の実装の脆弱性は階層検証にあった。ユーザーが渡した最上位の res バッファのみをチェックし、その後 res->ai_addr というユーザー制御可能なネストポインタを介して解析済みの socket アドレスを書き込むため、Smart/MMU ビルド下では1回の getaddrinfo() が任意カーネル書き込みになる。hints のフィールドは最上位の検証通過後もユーザーメモリから直接読み取られ、その間に TOCTOU ウィンドウが残る。servname のコピー戻り値の判定も誤っており、size_t と 0 を比較していて常に偽となる。

修正方法は lwp_get_from_user() で res と hints を一度にカーネルの一時構造体へコピーし、以降すべてのネストポインタはこの検証済みスナップショットに由来するものとする。ネストした sockaddr と外層の addrinfo は統一して lwp_put_to_user() で書き戻し、対象アドレス範囲は既存のヘルパーで検証され、カーネルは未チェックのユーザーポインタを参照解除しなくなる。併せて sizeof(*k_hints) に従ってカーネル addrinfo を割り当て、新規のエラー経路で k_res を解放する。

この変更の価値は行数ではなく、一つの書き方を示した点にある。ネストしたユーザーポインタに対し、階層検証は本質的に TOCTOU の隙間を持つため、一度のスナップショットこそが証明可能な安全への道である。作者は提案で、検証は K230 の RT-Smart 構成下で syscall_netdb.o のコンパイル通過のみを確認し、完全なビルドは CI に委ね、ユーザー空間の権限昇格の再現は行っていないと注記している。

1.2 DM365 の SPI 分周器でゼロ除算、max_hz に 0 を渡すと発生（11-03）

日付：2026-11-03 13:11（マージ時刻）　出典：提案 #11957、欠陥 #11950

6行追加、変更は bsp/dm365/drivers/spi-davinci.c のみで、今期間で最小の修正です。

davinci_spi_setup_transfer() は cfg->max_hz をそのまま davinci_spi_get_prescale() に渡し、後者が DIV_ROUND_UP(clk_get_rate(dspi->clk), max_speed_hz) を実行します。設定で max_hz が 0 かつデータ幅が正当な場合、この除算がゼロ除算となり、直ちに異常が発生します。修正方法は、プリスケーラを計算する前に max_hz == 0 を判定して -RT_EINVAL を返すことで、非ゼロレートの経路は変更しません。

検証条件は正直に書かれています。手元に DM365 ハードウェアはなく、実施したのは次の二点のみです。arm-none-eabi-gcc で bsp/dm365/drivers/spi-davinci.c をコンパイルし新たな警告が出ないこと。ホスト側で幅チェックとプリスケーラの二段ロジックを再現し、data_width = 9、max_hz = 0 のとき修正前は SIGFPE が発生し、修正後は -RT_EINVAL を返し、1 MHz のプリスケーラ結果は修正前と一致すること。DM365 は TI の ARM9 の旧プラットフォームで、この種の BSP は通常ほとんどテストカバレッジがなく、ゼロ除算の判定条件を補うだけでも純粋な利益です。

1.3 mailbox テストケースが 2 回目の実行で必ず失敗：4 つの完了フラグが一切クリアされない（11-03）

日付：2026-11-03 10:53（マージ時間）　情報源：提案 #11963、欠陥 #6565

11行追加、変更は src/utest/mailbox_tc.c のみです。

現象は、同一の起動内で 2 回目に core.ipc_mailbox を実行すると必ず失敗することです。1 回目は通過し、2 回目は受信スレッド内でアサーション rt_object_get_type(...) == RT_Object_Class_MailBox が失敗し、位置は _rt_mb_recv() の 2884 行目です。根本原因は、4 つの *_thread_finish フラグがワーカースレッドによって 1 に設定されるだけで、一度もクリアされないことです。2 回目の実行ではテスト本体の待機ループ while(static_mb_recv_thread_finish != 1 || ...) が直ちに通過してしまい、その結果 rt_mb_detach() が、今回の起動でまだ rt_mb_recv() にブロックしているワーカースレッドが終了する前に呼び出され、スレッドはその後エラーを伴って復帰し、すでに detach されたメールボックスを使い続けます。動的メールボックスの側も同じ形ですが、単独では触发されていません。

修正方法は utest_tc_init() でクリアすることです。このフックは utest フレームワークがテストケースを実行する前に毎回呼び出します。欠陥 #6565 は 2021 年に起票された古い課題で、この修正はその残り半分を修正するものです。

1.4 マクロコメントは行末か上方か：コーディング規約に判定基準を追加（11-03）

日付：2026-11-03 09:48（マージ時間）　情報源：提案 #11973、欠陥 #10097

72行追加、すべてドキュメント内です。coding_style_cn.md に 32 行、coding_style_en.md に 40 行を追加し、第 8 節にそれぞれ「マクロコメント」の節を補い、コードは一行も変更しません。

元の規約は「文のコメントはコードの上方または右方にのみ書く」とだけ述べており、マクロがどちらを選ぶべきか、その根拠については述べていなかったため、同じリポジトリ内で二つの書き方が併存していました。作者はまず現状を統計してから規則を定めました。include/ 下の 135 箇所のマクロコメントが行末 /**< を使用し、そのうち 87 箇所（64.4%）が 80 列を超え、kerrno.h の 24 行目は 95 列です。グループ化された定数マクロは意図的に列を揃え、超過を許容しています。したがって判定基準は行長ではなく、「どれだけ説明が必要か」です。1 行のコメントで説明できるなら行末に置き、一段落必要なら（引数付きマクロで、引数、展開結果、使用制限を記述する必要がある場合）上方に @def を付けて置きます。

ドキュメントはさらに実践上の違いを一つ補足しています。MACRO_EXPANSION を有効にすると、行末 /**< はマクロの展開点に付随し、同じマクロが複数箇所で展開されるとコメントの位置が予想外になることがあります。上方のブロックコメントは常に定義箇所にバインドされます。そのため頻繁に展開されるマクロは上方のブロックコメントを優先します。例はすべてリポジトリの実コード（kerrno.h のエラーコードグループ、rtdef.h の RT_ALIGN）から取られており、作られたものではありません。

2. セキュリティフォローとマージ待ちキュー

2.1 timerfd が任意の fd を受け入れる：2 つのシステムコールでカーネル PC 制御に（11-04）

日付：2026-11-04 01:08（報告時間）　情報源：欠陥 #11984

報告者XueDugu、ベースラインは master 5d1fb66d13（v5.4.0-dev）。影響範囲は明記されており、v5.0.2 から影響を受け、欠陥は 2023-09-23 の 7c2f807a（すなわち #8067 の timerfd システムコールのマージ）によって導入された。

問題自体は非常に短い。timerfd_do_settime() と timerfd_do_gettime() はプロセスの fd テーブルから任意のディスクリプタを取り出し、その df->vnode->data を無条件に struct rt_timerfd * にキャストする。このファイルが本当に timerfd かどうかの検証は行わない。Linux は同じ箇所で file->f_op != &timerfd_fops であれば -EINVAL を返すが、RT-Thread には対応するチェックがない。したがって、ユーザーが到達可能な任意の fd オブジェクトの vnode->data が timerfd として扱われる。カーネルは外部オブジェクト内で偽造ミューテックスを取得・解放し、攻撃者が与えた itimerspec を書き込み、さらに tfd->timer を逆参照する（任意の qword に対してリンクリストからの削除と rt_free を一回行う）。

本当に致命的なのは負の it_value.tv_sec である。これにより timerfd_timeout(tfd) が同期的に実行され、最初の文 rt_wqueue_wakeup(&tfd->timerfd_queue, POLLIN) が混乱したオブジェクトから読み出した待機キュー先頭をたどり、entry->wakeup(entry, key) を呼び出す——関数ポインタの間接呼び出しであり、ポインタと r0 はすべて攻撃者が選択したメモリに由来する。

報告は完全なチェーンを提供している。32 ビット RT-Thread 上では、signalfd が完璧な混乱オブジェクトであり、そのコンテキストの先頭 128 バイトは sigset_t sigmask で、signalfd() によってユーザーポインタからそのままコピーされる（NUL バイトを許可）。これで偽造 timerfd のヘッダを覆うのに十分であり、rt_mutex の type バイトをミューテックスタイプに設定し、owner を 0 にして take を即座に成功させ、timerfd_queue.waiting_list.next を設定することを含む。RT-Smart カーネルはユーザーとページテーブルを共有し、ユーザーマッピングを直接逆参照するため、偽造された待機キューノードは攻撃者自身のユーザーメモリに置かれる。

再現環境は qemu-vexpress-a9 に RT_USING_SMART デフォルトビルド（timerfd と signalfd は Smart 下でデフォルト有効）を加え、libc なしのユーザー態 ELF を /sbin/init として実行する。対照群は本物の timerfd への呼び出しで 0 を返し、カーネルは生存する。攻撃群は signalfd(-1, mask, 0) に timerfd_settime(sfd, 0, {it_value.tv_sec = -1}) を加え、カーネル prefetch abort を得る。PC は完全に制御可能で、三回の実行はバイト単位で一致し、レジスタに r00:0x10000 が見える。結論は、二つの非特権かついずれも公式 POSIX スタイルのインターフェースであるシステムコールで、カーネル制御フローのハイジャックが完了できるということである。

2.2 POSIX timer の id が検証されず、RT-Smart 上でコンソールデバイスを書き換え可能（11-03）

日付：2026-11-03 12:35（報告時間）　情報源：欠陥 #11980

同じ報告者による、同日のより早い時間のもの。timer_gettime() と timer_settime() はユーザーが与えた timer_t を直接インデックスとして扱う。timer = _g_timerid[(rt_ubase_t)timerid] であり、timerid < TIMER_ID_MAX のチェックはない。兄弟関数の timer_delete() にはこのチェックがあるので、これは設計上のトレードオフではなく、書き漏れである。

通常の MCU ビルドではこれは範囲外読み出しであるが、RT-Smart 上ではそれにとどまらない——攻撃者は _g_timerid の隣接アドレスに存在するポインタを選び、対象カーネルオブジェクトを struct timer_obj として再解釈できる。報告は QEMU イメージ内で見つけた具体的なエイリアスとして、インデックス 0x35a5（13733）が _console_device を指すことを挙げている。timer_settime() は続いて攻撃者が制御する itimerspec でこの稼働中の UART デバイスのフィールドを上書きし、rx_indicate と ops を含む。UART が受信バイトを一つ受けるだけで、制御フローは攻撃者が指定したアドレスにジャンプし、EL1 で実行される。

ハードウェア側でも検証された。Pico 2 W（RP2350）上で元の ctime.c と resource_id.c を用いてビルドし、逆アセンブルで timer_settime() の入口が ldr.w r6, [r5, r0, lsl #2] であることを確認。timer_oob に 0x20000000 を渡して実行するとアドレスは 0xa000202c と計算され、未マッピングであり、故障後 USB CDC 接続が消えるかシェルが停止する。ソフトウェアベースラインは同じく v5.4.0-dev で、導入コミットは 077e9841、最初の影響バージョンは v5.0.2。

2.3 ブロックデバイスパーティションの ioctl における任意カーネル書き込みなどが提案に到達（11-03）

日付：2026-11-03 15:51（提案時間）　情報源：提案 #11981、欠陥 #11952

19 行追加、5 行削除、1 ファイルのみの変更、作者は liangzhan5、提案ステータスは自らドラフトと記載。

問題は RT_DEVICE_CTRL_BLK_PARTITION にある。このコマンドはユーザー空間から渡された生ポインタをそのまま rt_memcpy の宛先アドレスとして扱うため、非特権プロセスがこれによって任意のカーネル書き込みを実現できる。さらに付随する不具合として、rt_memcpy の実行完了後に err が更新されないため、ioctl が最終的に -1 を返したとしても、宛先アドレスの内容はすでに書き換えられており、エラーコードと実際の状況が一致しない。作者は同時に、RT_DEVICE_CTRL_BLK_GETGEOME などのコマンドにも同種の問題がある可能性を指摘している。

修正方法は二つの経路に分かれる。RT_USING_LWP の下では lwp_self() を用いて現在がユーザー空間コンテキストかどうかを判定する。ユーザー空間であれば、まずパーティションデータをカーネルスタックの一時変数にコピーし、その後 lwp_put_to_user() で安全にコピーバックし、ポインタが不正な場合は -EFAULT を返して一切の書き込みを実行しない。非ユーザー空間（カーネル内部からの呼び出し）では従来の rt_memcpy 経路を踏襲し、err = RT_EOK を補う。検証は qemu-vexpress-a9 でのコンパイルと人手による確認までに留まる。

対応する欠陥 #11952 は 10 月 29 日に同じ報告者によって起票され、報告から提案まで 5 日である。

2.4 キュー：pipe パッチはまだ修正中、五件の旧件は引き続き保留（11-03）

日付：2026-11-03（提案更新時間）　情報源：提案 #11971、提案 #11954、提案 #11911、提案 #11918、提案 #11947、提案 #11935

前号で報じた pipe FIONREAD パッチ（#11971）は 11-03 16:13 に再び更新されたが、依然としてマージされていない。修正方法は変わらない。まずリングバッファのデータ長または残り容量をスタック上の int に計算し、MMU ビルドでは lwp_put_to_user() でユーザーアドレスにコピーバックし、非 MMU ビルドでは直接書き込みを維持する。併せて pipe と pipe->fifo の NULL チェックを補い、lwp_user_mm.h の include を ARCH_MM_MMU で囲む。

キューにある他の五件の状態：cromfs ディレクトリ名の境界（#11911）、poll と epoll のカウント乗算ラップアラウンド（#11954）、9pfs クライアントがサーバー長を信頼する問題（#11918）、DHCP アドレスプール枯渇後の無界探索（#11947）、signalfd クローズ時のリスナー摘除（#11935）は、いずれも本期マージなし。昨日マージされた #11978（GPT パーティションの先頭と末尾の逆転）はクローズ済みである。

3. 公式・コミュニティイベント

3.1 烏鎮「新光」：AIOS 基盤が選出、語られたのは仮想化ハイブリッドデプロイ（11-02 ~ 11-03）

日付：2026-11-02（博覧会開幕）/ 2026-11-03 14:30（公式コラム公開）　情報源：電子工程専輯：RT-Thread が烏鎮サミットに亮相、世界インターネット大会：博覧会が烏鎮で開幕、網信辦通稿

2026 年世界インターネット大会烏鎮サミットは 11 月 2 日から 5 日まで浙江省烏鎮で開催され、同時期の「インターネットの光」博覧会は 11 月 2 日午前に開幕した。公式発表によれば、54 の国と地域から 671 社の中外企業・機関が出展し、1000 余項の新技術・新製品を展示発表、35 項の「新光」製品と 20 項の「新耀」シーンを選定推介した。

RT-Thread 睿赛德がこのサミットで得た位置は「新光」製品推介リストであり、選出されたのは同社が自主イノベーションした「RT-Thread 異種融合端側智能AIOS基盤」である。エコシステムディレクターの李艶が博覧会現場で《仮想化ハイブリッドデプロイ具身智能方案·AI Kit》と題する基調講演を行った。

ベースの技術的主張は明確に書かれている。ハイブリッド配置アーキテクチャにより、AI 推論を Linux 側に、リアルタイム制御を RT-Thread 側に置き、両側が独立して動作し相互に干渉しない。たとえ AI 側に異常が生じても、制御側は安定して実行を続けられ、公式は制御精度がマイクロ秒級に達すると述べている。付属の AI Kit は推論エンジン、モデル最適化、ハードウェア適応、デバッグ環境を一つのツールチェーンにまとめ、「ある特定のチップ、ある特定のフレームワークに精通している必要はない」ことをセールスポイントとし、一つのツールセットで全プロセスを走り切れるようにしている。

この記事で記録する価値があるのは、ナラティブの口径の変化である。これまで RT-Thread が対外的に語ってきたのは「リアルタイム制御ベース」「出荷台数最大の国産組み込みオペレーティングシステム」だったが、今回選出された载体は端側インテリジェントオペレーティングシステムであり、着地点はロボットの「大脳」と「小脳」の協調である。公式発表にある「リアルタイム制御ベースから端側インテリジェントオペレーティングシステムへの鍵となる飛躍」という一文が、このナラティブの正式版である。数字の面では、原稿が示すコミュニティ規模は約 30 万人の開発者で、従来の口径と一致している。

3.2 オープンソース AIOS 連盟が小型具身知能を語る、RT-Thread は 3 種類の Agent 方案を説明（11-03）

日付：2026-11-03 17:14（報道時間）/ 2026-10-23（イベント時間）　情報源：鳳凰網：オープンソースAIOS連盟が WTCC 2026 に集結

11-03 になってようやく配信された商業プレスリリースで、10 月 23 日に上海西岸国際科技消費嘉年華（WTCC 2026）期間中に開催された「Jishu 創客坊：小型具身知能方案研討会」について書かれている。主催は安謀科技傘下の極術コミュニティで、同じ舞台に登壇したのは「オープンソース AIOS 連盟」の 3 社のパートナー、瑞芯微、瑞莎計算機、RT-Thread である。

安謀科技は今年 7 月にこの連盟を発起し、持続的知覚、自主実行、長期記憶などの能力に焦点を当て、同時期に JishuFriends と JishuBuddy という二つの落地成果を打ち出した。前者の初号プロトタイプ Puppy はロボット犬を载体とし、環境知覚、音声視覚インタラクション、自主移動を融合する。後者は Agentic AI 向けのハードウェア開発ツールで、自然言語を入口とし、Arm アーキテクチャの組み込みデバイスに適応し、シミュレーション環境に基づいて実在の具身デバイスと連動できる。

RT-Thread から登壇したのは AI シニアエンジニアの鄭炜で、ロボット犬、HyperCar、Codex 編排という 3 種類の Agent 方案について語り、着地点は知能体を「対話」から「実行」へと押し進めること、そして RT-Thread は具身知能プロジェクトを重点とし、安謀科技と協力して Agent 能力を実応用につなげていくことを明言した。3 社のパートナーの分担もこの原稿では比較的明確である。瑞芯微は主控 SoC と AI コプロセッサで演算力と制御を分離することを語り、瑞莎は ZERO 3W のようなオープンソースハードウェアでプロトタイプから量産納品までを担うことを語り、RT-Thread はシステム側の Agent スケジューリングと実行を語った。

注意すべきは時間関係である。イベントは 10 月 23 日で、報道は 11 月 3 日になってようやく現れた。今号で収録したのは、これが初めて RT-Thread の連盟内での具体的な技術分担を示したからであり、当日に新たに発生した出来事ではない。

3.3 公式ニュースインターフェースは依然 6 月で停止、リリースの出口は引き続きメディアコラム（11-04）

日付：2026-11-04（確認）　情報源：RT-Thread 公式ニュース一覧

公式ニュースインターフェース getList?type=rt_org が返す最新エントリは依然 2026-06-17 の「睿赛徳科技が 2026 アブダビ投資フォーラムに招待出席」であり、公式サイトのトップページニュース欄も同様に 6 月で止まっており、今号に新規追加はない。公式サイトのニュースモジュール自体が読み込みに失敗し（ページに「ああ、読み込みに失敗しました」と表示）、一覧ページはインターフェースでのみ確認できる。

実際のリリース出口はメディアコラムにある。今号は電子工程専輯の RT-Thread 公式コラムが 1 本更新され（11-03 の烏鎮「新光」原稿）、以前の 11-01 ダブル十一セール原稿はプロモーション内容に属するため未収録とした。フォーラム club.rt-thread.org は依然 468 を返し、前に WAF チャレンジページが置かれているため、スレッド一覧と本文を直接読み取ることができず、コミュニティ討論側は GitHub とメディアコラムによるクロス検証に頼るしかない。

4. エコシステムとベンダー適応

4.1 野火 HPM6750 BTB の Studio BSP が GitHub に公開、インストール手順を 5 ステップで記述（11-04）

日付：2026-11-04 03:47（リポジトリ作成）　情報源：リポジトリ：rt-thread-bsp-hpm6750-fire-btb

個人が維持する RT-Thread Studio ボードサポートパッケージで、ターゲットボードは野火の HPM6750 BTB 開発ボードである。README のパラメータ表はかなり揃っている。BSP バージョン 1.0.19、MCU は HPM6750IVM2（デュアルコア 32 ビット RISC-V、最高 816 MHz）、RT-Thread Full / Latest（実測では 5.4.0 上で動作）、ツールチェーンは RISC-V GCC 11.1.0、コンソールは UART0 の PY06/PY07（115200 8N1）、デバッグは外付け JTAG を使用（本ボードは SWD 非対応と明記）。

インストール手順は5ステップで書かれている。ReleasesからBSP ZIPをダウンロードし、StudioのSDKマネージャでリソースパッケージをインストールし、新規プロジェクト作成時にHPM6750-FIRE-BTBを選択し、RT-Thread Settingsでペリフェラルにチェックを入れ、コンパイル後にUSB、DAPLinkまたはJ-Link経由で書き込む。この書き方は先楫公式の一連のBSPリポジトリと同じパターンで、ただ維持管理者がチップ原廠から個人に変わっただけだ。

記録に値するのは、この種のリポジトリの出現頻度だ。昨日は先楫半導体が13分以内に12個の公式BSPをv1.13.0へプッシュしたことを報じたが、今日はサードパーティのボードでも同じプロジェクト構造で補完する人が現れた——BSPを独立リポジトリに分割し、Studioプロジェクト単位で維持するという約束事は、すでに原廠からコミュニティへと外溢し、デファクトスタンダードになっている。

4.2 新唐 N9H30 のコミュニティ BSP：HMI プラットフォームの ARM926EJ-S ベテラン（11-03）

日付：2026-11-03 20:13（プッシュ時間）　情報源：リポジトリ：sdk-bsp-nk-n9h30

新唐 N9HシリーズのコミュニティBSPで、対象チップはN9H30F61IECまたはN9H30F63IEC。これはARM926EJ-Sコア、最大300 MHz、TFT LCDコントローラと2Dグラフィックスアクセラレータを内蔵し、パラレルポートは1024x768、24ビットカラーまで駆動可能、オンチップに64 MB DDR、パッケージはLQFP216のMCP。

N9Hは典型的なヒューマンマシンインターフェースプラットフォームだ。演算能力は高くなく、表示とペリフェラルインターフェースは充実し、BOMは安価で、産業用HMI、入退室管理、家電パネルに適している。RT-Threadのこの種のMPU上のBSPは一貫してコミュニティが維持しており、新唐の公式サポートはMCUラインほど密ではないため、動作するリポジトリのそれぞれが選定の参考価値を持つ。

4.3 デュアル MCU 消毒装置：M7 が運動、M3 が噴霧を担当、両方とも RT-Thread で動作（11-03）

日付：2026-11-03 14:02（プッシュ時間）　情報源：リポジトリ：GD32

「浄巡衛士」というコンテストプロジェクトで、教室、廊下、公共の椅子など中小規模公共エリア向けのスマート消毒移動装置。アーキテクチャはデュアルMCU：GD32H759IMT6（Cortex-M7）が運動主制御、STM32F103C8T6（Cortex-M3）が噴霧制御を担当し、両方ともRT-Thread 4.1.1で動作する。

機能面は四輪差動移動、ロボットアームによる噴霧、HX711重量計測による残量監視、リモートコントロール、予約消毒、状態報告、映像伝送をカバーする。リポジトリ構造は多くのコンテストプロジェクトより整っており、docs/にはハードウェア説明、通信プロトコル、コードスタイル、コミット文書があり、scripts/にはKeilビルドとリポジトリ自己検査スクリプトがあり、clang-formatの設定も備えている。

この種のプロジェクトの見どころは技術的難易度ではなく、「M7一つでは足りず、M3を追加して分担する」というエンジニアリング上の取捨選択だ。運動制御はリアルタイム性が必要で、噴霧と残量監視は遅い変数であり、分離すれば2つのチップそれぞれに余裕が生まれ、通信コストはシリアルプロトコル1本で足りる。

5. 業界応用

5.1 RV32IM デュアルイシュー FPGA CPU が RT-Thread Nano を CoreMark 検証チェーンに接続（11-03）

日付：2026-11-03 20:58（プッシュ時間）　情報源：リポジトリ：RISC-V-CPU

Xilinx Kintex-7向けのRV32IMパイプラインCPUプロジェクトで、最近のプッシュで実験エントリを更新した。CPU側：RV32IM命令セット、マシンモードCSRとタイマー割り込み、メイン実行パスに整数サブパスを加え、条件を満たす2命令ペアリングをサポート。フロントエンドにはBTB、RAS、間接ジャンプ予測があり、メモリアクセス側にはデュアルパスフォワーディング、load/storeペアリング、キャッシュヒットバイパスがある。

ソフトウェア側がRT-Threadの着地点だ。動作するのはRT-Thread Nano v3.1.5で、UARTコマンドラインとCoreMark 1.0を備え、さらにオプションのcmcrc16カスタム命令もある。対象デバイスはxc7k325tffg900-2、Vivado 2023.2。

検証データは一般的なアマチュアプロジェクトより細かい。timingopt15に256行DCacheを加え、180 MHz理想クロックでCoreMark 100回の動作シミュレーションを行い、31,445,017 CPUサイクル、30,605,777退避命令、CPI 1.027421、最終CRCは0x988c、7項目の定向回帰が通過した。不足点も明記されている。180 MHz配線後WNSは-1.371 ns、WHSは+0.013 ns、タイミングは収束せず、bitstreamは未生成。100回シミュレーションは機能とCPI比較のみに使用し、ボード上の周波数は実装レポートに準拠する。

RT-Threadにとって、この意味はNanoが再び最小実行可能ソフトウェアスタックとしてCPU検証に使われたことだ——ベアメタルテストよりも、割り込み、コンテキストスイッチ、タイマーパス上の問題をよりよく露出できる。

6. 本期トレンドと総括

6.1 トレンド：セキュリティ側はレポートから提案へ、テスト側はチェックリストからコードへ

本期24時間では、メインリポジトリに4件がマージされ（#11977、#11973、#11963、#11957）、新規提案が4件（#11979、#11981、#11982、#11983）、新規不具合が2件（#11980、#11984）作成された。件数は前期と横ばいだが、構造は変化した。前期はバックログの解消だったのに対し、本期は新規案件の起票とインフラの補強である。

第一条線はセキュリティ側の新規報告2件で、形状が高度に一致している。いずれも「記述子または識別子に型検証を行っていない」というものだ。timerfdはfdがtimerfdかどうかを検査せず、POSIX timerはidが範囲外かどうかを検査せず、両エントリともユーザーが与えた値をそのままカーネルオブジェクトへの入口として扱う。これに前期のグラフィックス負オフセット（ユーザー指定のオフセットの符号を検証しない）とpipe（ユーザーポインタを検証しない）を加えると、4件は同一カテゴリに分類できる。RT-Smartのシステムコール層において「値 → オブジェクト」の段階で統一的な検証が欠けているのだ。この種の不具合の修正自体は複雑ではない。難しいのはすべての入口を見つけ出すことである。

第二条線は対応速度が速まっていることだ。#11952は10月29日に報告されたブロックデバイスパーティションの任意書き込みだが、11月3日には提案#11981が作成された。昨日のgetaddrinfo再実装（#11977）は本日マージされた。pipeパッチはキュー内で継続的に更新されている。報告、提案、メンテナによる再実装、マージという4段階が数日で完了できるようになり、前期の「報告が多くパッチが少ない」という判断と比較して明確な変化である。代償としてレビュー負荷がメンテナ側に移っており、キューには依然5件が審査中で、いずれも誰かが再現手順を理解する必要がある。

第三条線はZバージョンのテストリストがコードを生み出し始めたことだ。前期に報告した#11972は「Zバージョンをリリースできるか」をフレームワークごとのQEMUとutestのリストに分解したが、本期はそれを直接参照する提案が3件登場した。SPIのファームウェア内仮想ループバックバス（#11979）、I2Cフレームワークの模擬バスutest（#11982）、そして自動実行にループとメモリサンプリングを追加する#11983（これは#11963の後続で、「1回だけの実行ではメモリリークを発見できない」を解決する）である。本日マージされたmailboxテストケースの反復実行可能化と合わせ、CI側のテスト基盤は「反復可能・観測可能」へと向かっている。

エコシステム側では逆方向の2つの動きが注目に値する。一方はチップ原廠がBSPリポジトリをスクリプト化して一括リリースする動き（先楫の昨日の12リポジトリ同一バージョン）であり、他方は個人開発者が野火HPM6750 BTBのようなサードパーティボード向けにStudio BSPを補完し、新唐N9H30のような旧プラットフォーム向けにコミュニティBSPを補完する動きだ。ベンダーがボード間の一貫性を保証し、コミュニティがロングテールのカバレッジを埋める。この両者が合わさってこそRT-Threadのボードレベルエコシステムの全貌となる。

イベント側では、烏鎮「新光」が本期最も重要な項目である。国家級プラットフォームが「異種融合端側智能AIOS基盤」を35項の推薦製品に組み入れ、ナラティブは「リアルタイム制御基盤」から「端側智能オペレーティングシステム」へと転換し、着地点はロボットの「大脳」と「小脳」の協調にある。同日に登場したWTCC連盟の稿は、まさにこのナラティブを具体シナリオに落とし込んだバージョンである。3類のAgent方案、安謀科技との分業、具身智能を重点とする内容だ。宣伝とエンジニアリングが同一線上にあり、これは従来のイベント稿ではあまり見られなかった。

6.2 限界と重複排除の説明

フォーラムclub.rt-thread.orgは本期も468を返しWAFチャレンジページが前置され、スレッド一覧と本文を読み取れず、コミュニティ討論側の情報ギャップはGitHubとメディアコラムで補完した。公式ニュースAPIと公式サイトのニュース一覧はいずれも6月17日で停止しており、公式サイトのニュースモジュール自体が読み込みに失敗する。

GitHub匿名APIのレート制限（毎時60回）が収集後半で枯渇したため、組織レベルの全量プッシュは13の重点リポジトリのAtomコミットフィード検査（packages、env、rtthread-nano、sdk、smart-build、UtestRunner、userappsなど）に切り替え、期間内はいずれもコミットなし、メインリポジトリのみプッシュがあった。不具合#11950はタイトルと要約のみ取得し、本文は未読。#11984と#11980のPoC詳細はすべて報告本文からの引用で、独立した再現は行っておらず、報告中では原文の限定条件（QEMUモデル、ベースラインコミット、影響バージョン）に従って記述している。

Google News中国語側は3日間で5件ヒット、収録2件（烏鎮「新光」、WTCC連盟稿）。双十一セール稿はプロモーションであり期間外のため未収録、上海オープンソースコンテスト稿は前期に既報。英語側は2組のクエリでゼロヒット。HN Algoliaは期間内5件すべてがThread組網プロトコル、採用ボード、Mbed TLSメンテナンスで本主題と無関係のため除外した。

重複排除：昨日報告した#11977提案は本期マージされ、「進展」として処理し1件と記録した。#11971、#11954、#11911、#11918、#11947、#11935は前期に既掲載のため、本期は状態変化のみ記録し重複して項目化しない。#11978は昨日クローズ済みのため本期は展開しない。

付録：情報源核查表と情報源リスト

情報源核查表

情報源 調査結果
公式ニュースインターフェース（rt_org） 24時間で新規なし、最新項目は2026-06-17で停止
公式サイトニュース一覧 トップページのニュース欄は依然6月のまま、ニュースモジュールの読み込み失敗
コミュニティフォーラム 前置WAFチャレンジページ（HTTP 468）、一覧と本文を読み取り不可
メインリポジトリ commits 調査期間内に4件、集中して11-03 09:04～13:11
メインリポジトリ PR マージ4件（#11977、#11973、#11963、#11957）、新規4件（#11979、#11981、#11982、#11983）
メインリポジトリ Issue 新規2件（#11980、#11984）、いずれもRT-Smartセキュリティ問題
メインリポジトリ releases と tags 新規なし、最新は依然v5.3.0（2026-09-10）
RT-Thread org 重点リポジトリ 13リポジトリのAtom調査、調査期間内にいずれもコミットなし
GitHub リポジトリ検索 RT-Thread関連リポジトリ2件新規（HPM6750 BTB BSP、N9H30 BSP）、topicヒット3件
Google News 中国語 3日以内に5件、収録2件（烏鎮新光、WTCC連盟稿）
Google News 英語 ヒットゼロ
HN Algolia 5件はいずれもThreadプロトコルまたは求人内容、本主題ではない
電子工程専輯公式コラム 11-03に烏鎮稿1件、収録済み
世界インターネット大会公式サイト / 網信辦 博覧会開幕と35項目の「新光」表現、公式稿の照合に使用

完全な情報源リスト

www.cac.gov.cn/2026-11/02/c_1795373863477368.htm>