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

情報源：RT-Thread 公式ニュースインターフェースと公式サイトのニュース一覧、GitHub メインリポジトリの commits / PR / Issue / releases / tags、RT-Thread org リポジトリのプッシュ一覧、GitHub リポジトリ検索（topic:rt-thread と rt-thread キーワード）、Google News の中国語・英語 5 グループのクエリ（プロキシ経由）、HN Algolia、電子工程専輯 RT-Thread 公式コラム、楽鑫（Espressif）公式リリース稿、club.rt-thread.org フォーラム（今号もサイトの WAF 制限を受けています）

今号のインデックス

    1. カーネルとバージョン動向
      • バージョン番号とリリースプロセスが初めて文書化：Z バージョンは毎月、Y バージョンは 3～6 か月（11-04）
      • シリアルポートの TIOCGWINSZ をデバイスに直接問い合わせる方式に変更：tshell 経由の文字読み取りを廃止（11-04）
      • GPT パーティションの先頭と末尾が逆転していた問題にチェックを追加：アンダーフローした巨大パーティションは登録されなくなる（11-04）
    1. セキュリティフォローとマージ待ちキュー
      • MSI-X テーブルの BIR とオフセットが未検証で、悪意ある PCIe デバイスがプローブ段階で任意の物理アドレスに書き込み可能（11-05）
      • 報告から 6 時間で修正提案：5 項目のチェックを一度に補完（11-05）
      • キュー：ブロックデバイスパーティションのパッチにまた更新、4 件が引き続き保留中（11-05）
    1. 公式・コミュニティイベント
      • 睿擎 RK3576 デスクトップペット：ボードが聞くことと話すことを担い、PC が考えることを担う（11-04）
      • 公式ニュースインターフェースは依然 6 月で停止、メディアコラムが唯一の安定した出口（11-05）
    1. エコシステムとベンダー適配
      • ESP32-S31 上で RT-Thread を ESP-IDF に組み込み：36 項目のセルフチェックがすべて合格（11-04）
      • coact：1 つのヘッダファイルで RT-Thread、FreeRTOS、Linux を同時にサポート（11-04）
    1. 今号のトレンドとまとめ
      • トレンド：攻撃面がシステムコールの引数からデバイスファームウェアへ移動
      • 限界と重複排除の説明

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

1.1 バージョン番号とリリースプロセスが初めて文書化：Z バージョンは毎月、Y バージョンは 3～6 か月（11-04）

日付：2026-11-04 10:44（マージ時刻）　出典：提案 #11955、議題 #11956

751 行追加、14 ファイル、すべてドキュメント：中国語・英語の 2 部構成の「バージョン番号制定と実施細則」および「バージョンリリースプロセス」、6 枚のフローチャート付きで、Doxygen インデックスに登録され、ドキュメントセンターとともに公開される。作者は kurisaW、10 月 30 日に提出され、今期間の冒頭でマージされた。ドキュメント自体にはバージョン 1.0、日付 2026-10-27 と記載されている。

ルールの核心はバージョンのリズムを数字で書き表すことにある：Z リビジョンは原則毎月 1 つ、Y マイナーバージョンは機能の蓄積とメンテナンスリソースに応じて 3～6 か月ごとに 1 つ、X メジャーバージョンは固定周期ではリリースしない。バージョン番号は vX.Y.Z を採用し、ソースコード内の RT_VERSION_MAJOR/MINOR/PATCH、Git Tag、Release、成果物名と一致しなければならない；日常のコミットではバージョン番号を上げず、開発スナップショットはターゲットバージョンに完全な SHA を付けて識別するのみとする。

段位の判定基準はこれまでになく細かく示されている。X のトリガー条件は、カーネルの交換、デバイスモデルやドライバフレームワークの交換、複数のコアサブシステムの協調アップグレード、および既存プロジェクトの移行を必要とする API、ABI、Kconfig、起動フローの変更である。Y に求められるのは「カーネルまたはコンポーネント API の新規追加、独立した納品能力を形成する BSP 群の新規追加、複数の小機能が集まって完全に検証可能な集合になること」であり、明確に一言書かれている：単一の散発的な機能、部分的なパラメータ拡張、単一実装の最適化は自動的に Y をトリガーしない。Z は欠陥、セキュリティ、性能、単一 BSP 適配、ドキュメントのみを扱い、新しい公共 API、コンポーネント、ドライバフレームワークを導入してはならない——単一 BSP が新しいドライバフレームワークを持ち込む場合は、Y または X に上げなければならない。同一バージョンで複数種の変更が混在する場合は、X は Y より高く、Y は Z より高いという原則に従い最高位を取る。コミット数、PR 数、コード行数は見ない。

実施細則の中で下流にとって最も有用なのは以下の几条：Y の周期は一度決めたらバージョン目標に書き込まなければならず、期間内に検証しきれない機能は順延する；Z リリース前の約 1 か月は修正収束に入り、Y リリース前の約 1 か月は機能収束に入り X.Y を凍結する；正式リリース後に問題が見つかった場合は X.Y.Z+1 をリリースするのみで、元の Tag、元の Release 内容、元の成果物を変更してはならない；デフォルト動作やリソース占有を変更する Y、Z バージョンは Release に明記しなければならない。付随する「バージョンリリースプロセス」は 1 回のリリースを 6 つの段階に分解する——バージョン準備、次バージョンの初期目標策定、開発準備、開発、プレリリース、リリース。プレリリース部分には機能収束、BUG リグレッション、アーキテクチャと BSP でグループ分けしたテストケーステンプレートが含まれる。

注目すべきは、ドキュメントの例が統一して v6.0.0、v6.1.0、v6.1.1 と書かれており、次のメインラインは 6 系列で計画されていることだ。これまで 5.2 と 5.3 の間隔、Z バージョンのリズムは実践の中でしか現れていなかったが、今回初めてリズム、判定基準、リリース後に Tag を変更できないという几条をリポジトリ内の正式ドキュメントとして書き表した。アップグレードコストを判断する下流のディストリビューションや商用バージョンにとって直接利用可能な根拠となる。

1.2 シリアルポートの TIOCGWINSZ をデバイスに直接問い合わせる方式に変更：tshell 経由の文字読み取りを廃止（11-04）

日付：2026-11-04 21:33（マージ時間）　情報源：提案 #11891

136 行追加、153 行削除、dev_serial.c、dev_serial_v2.c、serial_tty.c の三ファイルを変更、四つのコミット、メンテナ BernardXiong 自身による提案で、10 月 18 日に開始、本期マージ。

旧実装には二つの不具合があった。一つは tshell スレッド内でしか使えないこと：finsh_getchar() で端末の CSI 応答パケットを読むため、tshell 以外のスレッドからの呼び出しではあっさり 80x24 を返していた。もう一つは入力を食うこと——応答パケットは shell の入力チャネルから入ってくるため、ユーザーが入力中の文字を飲み込む可能性がある。さらに termios は設定のたびに無条件で ops->configure を呼び、純粋なソフトウェアパラメータの変化でも UART の FIFO をリセットしていた。

新しい書き方では問い合わせコマンドを直接シリアルデバイスに書き込み（CSI 18 t の四バイトを書き込み）、応答パケットを一バイトずつ読み、総待機 200 ミリ秒、’t’ を読んだら終了する；応答パケットは厳密に CSI 8;rows;cols t の形に一致しなければならず、行も列も 1 から 999 に制限され、いずれかの段階で不一致なら既定の 80x24 を保持し、もはや atoi で勝手に解析しない。v2 版ではさらに一歩進んで：問い合わせ期間中は RX タイムアウトを一時的に RT_WAITING_NO に変更し、端末が応答しない場合に読み取り操作が永久にブロックするのを避け、読み終わったら元に戻す。

termios 側は先に比較してから設定する方式に変更：新構成が serial->config とバイト単位で同一なら ops->configure を呼ばない；tty 側ではシリアルを開く際にそれがコンソールかどうかを判断し、そうであれば先にウィンドウサイズを一度問い合わせてから bypass を装着し、これにより応答パケットは生の受信キューに残り、入力に変換されない。元々 ioctl 内にあった ENOSYS だけを行う switch も併せて削除した。

検証条件は率直に書かれている：BSP は bsp/k230 と bsp/qemu-virt64-aarch64 を使用し、作者はローカルで実行しておらず、その理由は環境に RISC-V musleabi ツールチェーンがないためで、CI のコンパイルに委ねている。この種の「一つのアーキテクチャ上だけで考え抜き、CI に委ねる」コミットはシリアル層では珍しくないが、変更の方向性は正しい：端末サイズはデバイス属性であり、特定の shell スレッドの存在に依存すべきではない。

1.3 GPT パーティションの先頭と末尾が逆転していたのに検証を追加：アンダーフローした巨大パーティションは登録されなくなる（11-04）

日付：2026-11-04 21:30（マージ時間）　情報源：提案 #11978、不具合 #11271

11 行追加、5 行削除、ブロックデバイスのパーティション解析を行う efi.c 一ファイルのみを変更。これは期限切れの提案 #11275 のやり直しである。

is_pte_valid() は元々 starting_lba と ending_lba の両方がディスク範囲内に収まることだけを要求し、ending_lba が starting_lba 以上であることを検査していなかった。CRC 検証が合法な GPT イメージを構築すれば、efi_partition() 内の size = ending_lba - starting_lba + 1 で符号なしアンダーフローが発生し、天文学的なパーティションサイズを得て、論理パーティションとしてシステムに登録できてしまう。改修は二段階：is_pte_valid() に end が start より小さい場合の判定を加えて直接拒否する；start と size の計算を合法性検査の後に移し、検証済みの start から size を導出し、根本からアンダーフロー式が評価されないようにする。

一点訂正が必要：前号レポートでは提案ステータスに基づき #11978 を「クローズ済み」と書いたが、実際のマージタイムスタンプは 11-04 21:30（北京時間）であり、本期の調査期間内に該当するため、本期でマージとして追記する。同じ修正に対応する不具合 #11271 は 3 月 19 日に起票され、不具合からマージまで七ヶ月余りを要した。

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

2.1 MSI-X テーブルの BIR とオフセットを検証せず、悪意ある PCIe デバイスがプローブ段階で任意の物理アドレスに書き込む（11-05）

日付：2026-11-05 01:12（報告時間）　情報源：不具合 #11985

報告者は依然として XueDugu、ベースライン master 5d1fb66d（v5.4.0-dev、2026-10-15）、影響範囲は v5.2.0 以降と明記され、2024-05-30 の 2168ed8e7（PCI/PCIe バスフレームワーク初回マージ）により導入された。

問題は msix_table_remap() にある。デバイス側の読み取り専用レジスタである MSI-X Table Offset を読み、下位 3 ビットを BIR として、そのまま pdev->resource[] のインデックスに使っている。しかしこの配列は 6 項目しかないのに、BIR は 0x7 でマスクされるため、6 と 7 を取り得る。6 を取るとちょうど構造体内で隣接する pdev->rom にエイリアスする——option ROM を持たないデバイスでは、このメンバは {base:0, size:0, flags:0} である。PCI_BUS_REGION_F_MEM の値が 0 であるため、「BAR 未割り当て」の空判定条件（flags と F_NONE の論理積）はかえって通過し、その結果 table_base_phys = 0 にオフセットを加えた、完全にデバイスが決める絶対物理アドレスとなり、29 ビット幅で参照ボードの全メモリを覆うのに十分である。

さらに二つの検証も欠けている。table_offset は最大 0xFFFFFFF8 まで取り得るが、BAR の size と一切比較されない。entries_nr は MSI-X Control レジスタのもう一度の読み取りに由来し、デバイスが二回の読み取りで異なる値を返せば、最後の各表項に 0x80000000 を書き込むループをマッピング領域の外まで走らせることができ、最大 2048 項、32 KB に達する。さらに重要なのは、rt_ioremap() 自体が物理アドレスの合法性チェックを行わないため、偽造されたマッピングは成功してしまうことである。

再現チェーンは完全である。公式 qemu-virt64-aarch64 のデフォルト設定（RT_USING_PCI、RT_PCI_MSI、RT_PCI_ECAM、RT_NVME_PCI、RT_PIC_ARM_GIC_V2M をすべて有効）で、ローカルでパッチを当てた QEMU nvme モデルを使い、デバイス側の MSI-X Table Offset を 0x4023f06e、すなわち rt_interrupt_enter_hook のアドレス 0x4023f068 に BIR 6 を論理和した値に偽造する。起動時に pci_nvme_probe が順に msix_capability_init と msix_table_remap へと進み、カーネルはその後 MSI doorbell 値 0x08020040 をその物理アドレスへ書き込む。次に割り込みが発火したとき、異常ログの EPC は 0x08020040 となり、システムは無限ループに入る。報告には GDB の観測点、コンソールログ、メモリの前後比較が示されており、攻撃グループの三回の実行結果はバイト単位で一致している。

定性は抑制的に書かれている。CVSS 3.1 は 6.8（AV:P）で、スコアは物理的接触または周辺機器のサプライチェーンという前提に抑えられているが、技術的な帰結は起動段階におけるカーネルの任意物理メモリ読み書きである。攻撃の前提は悪意あるいは改ざんされた PCIe デバイス（悪意あるファームウェアの NVMe ドライブ、すり替えられた周辺機器、露出した M.2 スロット）であり、いかなるソフトウェア権限やユーザー操作も必要としない。CWE-787、CWE-129、CWE-20 を関連付け、v5.2.0 から v5.3.0 および master のいずれも影響を受けると検証されている。報告者は同時に、PCI フレームワークにはこれまでセキュリティ監査の対象となったことがなく、この件は既存の報告のいずれとも重複しないと指摘している。

2.2 報告後 6 時間で修正提案：五つの検証を一度に補完（11-05）

日付：2026-11-05 07:21（提案時刻）　情報源：提案 #11986

47 行追加、5 行削除で、PCI の MSI-X コアファイル msi.c のみを変更し、メンテナの BernardXiong が提出したもので、状態は依然としてレビュー待ちである。

五つの検証は報告にある三つの欠陥と二つの細部に対応する。BIR が resource 配列の長さ以上なら直接拒否する。BAR が未割り当てとマークされているか size が 0 なら直接拒否する。table_offset に entries_nr 掛ける 16 を加えたものが完全に BAR 内に収まらなければならない（ついでに table_offset を PCIM_MSIX_TABLE_OFFSET マスクで整える）。設定レジスタ読み取りの戻り値を検査し、読み取り失敗時は続行しない。nvec が table_size を超える場合は拒否し、デバイスが二回の読み取りで不一致な表サイズを返すのを防ぐ。計算側では table_base_phys と table_bytes を 64 ビットに引き上げ、加算が 32 ビットでオーバーフローするのを避ける。

検証はコンパイルまでに留まる。bsp/qemu-virt64-aarch64 で RT_USING_PCI と RT_PCI_MSI を有効にし、xPack aarch64-none-elf-gcc 13.2.1 で通過したが、攻撃の再現は行っていない。01:12 の報告から 07:21 の提案まで、六時間九分であり、これは本テーマでこれまで最速の「報告からパッチまで」である。

2.3 キュー：ブロックデバイスパーティションパッチにまた更新、四件が引き続き保留中（11-05）

日付：2026-11-05（提案更新時刻）　情報源：提案 #11981、提案 #11954、提案 #11971、提案 #11983

前回報告したブロックデバイスパーティションのユーザーポインタ強化（#11981、欠陥 #11952 の任意カーネル書き込みに対応）は 11-05 07:34 に再度更新があったが、依然としてマージされていない。修正方法は変わらず、ユーザー空間コンテキストでまずパーティションデータをカーネルスタックにコピーし、その後 lwp_put_to_user() で書き戻す。不正なポインタは -EFAULT を返し、書き込みは行わない。

キューにある他の3件の状態：poll と epoll のカウント乗算ラップアラウンド（#11954）は 11-05 00:04 更新。pipe ioctl のユーザーポインタ強化（#11971）は 11-04 14:57 更新。自動実行にループとメモリサンプリングを追加する utest 提案（#11983）は 11-04 12:44 更新。3件ともレビュー待ち。前回マージされた #11978 は今回でクローズ済み。#11977、#11973、#11963、#11957 もすべてクローズ済みで、バックログはこれ以上厚くなっていない。

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

3.1 睿擎 RK3576 デスクトップペット：ボードが聞くことと話すことを担い、PC が考えることを担う（11-04）

日付：2026-11-04 13:54（コラム公開時刻）/ 2026-11-04 20:00（ライブ配信時刻）　情報源：電子工程専輯：睿擎プラットフォーム、RK3576 で青いクジラを飼う

RT-Thread 公式コラムは 11-04 にエンジニアリング振り返り記事を公開し、DeepSeek Harness にいるあの青いクジラを RK3576 と小さな画面に移植する方法を説明した。KEY5 を押して一言話すと「diii」と鳴き、数秒後に大きな太った魚の口調で一言返し、画面上の目がそれに合わせて動く。同日 20:00 に睿擎技術ライブ配信室で実機デモを行った。

役割分担は明確に書かれている。ボードが聞くことと話すことを担い、PC が考えることを担う。ボード側は RK3576 と ES8388 サウンドカードを搭載し、録音は arecord、再生は aplay で、いずれも hw:0,0 を経由する。表情は GPU を使わず、Qt や LVGL も動かさず、直接 mmap で /dev/fb0 を開いてピクセルを書き込む。人設、記憶、ツール、モデルはすべて PC の DSH Desktop 上にあり、ボードは API Key を保存せず、推論も行わない。PC の電源が入っていなければボードは黙ってしまう。

1 回の対話は 7 ステップに分解される。evdev が KEY5 を読み取るとプロンプト音を鳴らして録音を開始。arecord は 16 kHz、S16_LE、ステレオで WAV に録音。voice-once はファイルを multipart POST で中継サービスの /v1/voice-turn に送信。server.mjs は WAV ヘッダーを剥がし、f32 PCM に変換して ASR に送る。session.prompt は「受理済み」だけを返し、本文は session.history をポーリングして安定するまで待つ。spokenForTts は【】内の文字だけを選んで Edge TTS に渡し mp3 を合成。ボード側は mpg123 で WAV に変換し、sox で 48 kHz にリサンプリングし、aplay で音を出す。同時にレスポンスヘッダーの表情マークに従ってフレームを切り替える。

なぜ中間にブリッジを挟むのか、記事は2つの具体的な理由を挙げている。api.deepseek.com はテキストインターフェースしかなく、/v1/audio/ 系のエンドポイントがないため、ボード側の直接接続では音声チェーンを組めない。会話の連続性には固定の DSH_SESSION_ID が必要で、音声で新たなセッションを開くと人設とコンテキストがすべて変わってしまう。ブリッジはブロッキングで、ボード側の curl は 180 秒のタイムアウトを持ち、キー押下から音声が返るまでずっと待機する。

3つの落とし穴は結論よりも価値がある。第一に、1回のキー押下で2回の対話が走ってしまったこと。デーモンプロセスが殺されても子プロセスが必ずしも一緒に死ぬとは限らず、2つのプロセスが同時に同じ event7 を読んでいた。補修方法は flock による単一インスタンス化、EVIOCGRAB によるデバイス独占、起動時に /proc の fd に基づいて孤児プロセスをクリアすることの3つで、どれか1つ欠けると再現する。第二に、ストリーミング TTS が途切れること。コード内の DSH_VOICE_TTS_SSE スイッチはデフォルトでオフになっており、コメントには often truncates と直接書かれている。初期は最初のセグメントを取得するとすぐ合成し、一言がわずか 10 KB だった。「連続して複数回ポーリングしても内容が変わらず、かつ読み上げが少なくとも2つの漢字を含む」場合にのみ合成するよう変更し、サイズは 115 KB になった。第三に、表情は2段階の優先度があり、idle、listening、speaking が 0、感情が 1 で、1 がロックされている間は 0 のリクエストは直接無視される。ロックが期限切れになると自動的に idle に戻らなければならず、そうしないと confused の再生後に最後のフレームで止まってしまう。

この記事の価値は、「リアルタイム IO はボード側に残し、推論はより強力な演算側に置く」ということを再現可能な7ステップのチェーンとして書き出した点にある。烏鎮の「新光」記事にある AI を Linux 側に、制御を RT-Thread 側に置くという分担と同じ考え方だが、今回は推論が PC に移されている。今後の計画は LVGL インターフェース、割り込みメカニズム、大規模モデルによるハードウェア制御である。

3.2 公式ニュースインターフェースは依然6月で停止、メディアコラムが唯一の安定した出口（11-05）

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

公式ニュースインターフェース getList?type=rt_org が返す最新エントリは依然として 2026-06-17 の「RT-Thread 睿赛德科技、2026 アブダビ投資フォーラムへの招待出席」であり、公式サイトトップのニュース欄も同様に6月で停止しており、今回は新規追加なし。公式サイトのニュースモジュールのリスト領域は依然としてインターフェースで照合しないと完全には読めない。

実際の公開経路はすでにメディアコラムで安定している。今号の『電子工程専輯』の RT-Thread アカウントが睿擎デスクトップペットの原稿を1本更新し、収録済みとなった。フォーラム club.rt-thread.org は依然として 468 を返し、先頭に WAF チャレンジページが付くため、投稿一覧と本文を直接読み取ることはできず、コミュニティ議論側は GitHub とコラムのクロスチェックに頼るしかない。

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

4.1 ESP32-S31 上で RT-Thread を ESP-IDF に組み込む：36 項目のセルフチェック全通過（11-04）

日付：2026-11-04 20:56（プッシュ時間）　情報源：リポジトリ：esp32s31-rtthread、楽鑫：ESP32-S31 リリース稿

RT-Thread 5.4.0 を ESP32-S31 に移植したリポジトリで、形態はよくある BSP ではなく、自身を ESP-IDF v6.1 のコンポーネントにするものだ。component/ はそのまま esp-idf/components/rtthread にドロップインして FreeRTOS カーネルを置き換える。patches/ は git apply で IDF 自身の 10 ファイル・約 440 行を変更する。内容は freertos の Kconfig と CMakeLists、起動フロー、リンカスクリプトの割り込みスタックとヒープセグメント定義、さらに新規追加の RISC-V トラップ入口と flash クロスコアフックを含む。project/ はサンプルアプリのみを置く。RT-Thread のソースコードはゼロ修正を保ち、スクリプトが固定コミット 9e6dec3b で 5.4.0 を取得する。

機能一覧は非常に具体的だ。スケジューリング、スレッド、セマフォ、ミューテックス、イベント、メールボックス、メッセージキュー、ソフトウェアタイマー、動的・静的オブジェクトが揃う。SMP デュアルコアスケジューリング（各コア独立 tick、独立割り込みスタック、IPI）、CLIC 割り込みとハードウェアネスト、割り込みウォッチドッグ、FinSH の 22 コマンド、内部 DRAM に 16 MB PSRAM を加えたヒープが利用可能。ペリフェラル側は UART、GPIO とピン割り込み、3 系統 I2C、SPI（ポーリング、完全なバスフレームワークではない）、2 系統 17 ビット ADC、8 系統 LEDC PWM、MCPWM の相補とデッドタイム、4 系統 GPTimer、PCNT、RMT、TWAI がすでに接続済み。ワイヤレス側は Wi-Fi 2.4 GHz が接続して IP を取得でき、スキャンも可能、BLE コントローラと NimBLE が使用可能。未移植なのは I2S、SD/MMC、LCD、カメラ、タッチ、イーサネット、ハードウェア暗号化と低消費電力だ。

ボード上での結果は 36 項目のセルフチェックが全通過、失敗 0、デュアルコアともスレッドが動作し、Wi-Fi はデュアルコア有効下で接続して IP を取得できる。記事中の3つの非自明な設計ポイントは記録に値する。CONFIG_FREERTOS_UNICORE=y と「デュアルコア」は矛盾しない。この2つのマクロは FreeRTOS がマルチコア上でスケジューリングするかどうかを記述するもので、y に設定すると IDF は start_other_core を呼ばず、第2コアは RT-Thread 自身の起動に残される。n に設定すると逆に entry() がまったく呼ばれなくなる。CPU1 はまず mstatus.FS を 3 に設定する必要がある。トラップ入口が浮動小数点幅 32 のとき無条件に f0 から f31 まで保存するためだ。スレッドスタックフレーム構築時に FS は 3 だが、CPU1 の電源投入時は 0 であり、この一手を補わないと最初の浮動小数点保存でエラーになる。

背景は楽鑫が 2026 年 3 月 26 日に発表した ESP32-S31 だ。デュアルコア 32 ビット RISC-V、最大 320 MHz、Wi-Fi 6、Bluetooth 5.4、802.15.4 を備え、公式ソフトウェアスタックは ESP-IDF と FreeRTOS。このプロジェクトはカーネルを交換しつつ IDF のワイヤレスファームウェアとドライバを保持する。つまり、ベンダーが1種類の RTOS しか提供しないチップ上で、別カーネルのプラガブル性を検証したことになる。位置づけは正直に書かれている。host とマルチアーキテクチャ移植はテスト参考にすぎず、製品目標は依然としてシングルコア MCU だ。

4.2 coact：1つのヘッダファイルで RT-Thread、FreeRTOS、Linux を同時に接続（11-04）

日付：2026-11-04 22:35（プッシュ時間）　情報源：リポジトリ：coact

C++17 のアクティブオブジェクトと階層状態機械フレームワーク。作者は DeguiLiu、MIT ライセンス、今調査期間で 98 スターまでプッシュされた。モデルは QP/C++ の路線に沿う。イベントがスレッドに取って代わり、振る舞いは階層状態機械として記述され、遷移表は constexpr で、実行期に一切の割り当てを行わない。同一のヘッダファイルが RT-Thread、FreeRTOS 上で動作し、Linux と Windows 上でも PAL を通じてコンパイルできる。host はテスト参考のみだ。

それは三つの性質を構造的制約として書き、「スローガン」にはしていない。有界：各キュー、メモリプール、バッチサイズはいずれもコンパイル時定数であり、ヒープも new も delete もなく、動的登録もない。最悪時のフラッシュと RAM の占有量はリンク時に確定でき、リポジトリには Renode 上での占有量スクリプトが含まれている。検出可能：コミット結果は SubmitResult 戻り値で返され、さらに Monitor カウント、Breaker::level()、fatal_assert 処理がある。失敗時にはその発生箇所で、どのアクティブオブジェクト、どの区画に属するかを確認できる。回復可能：各アクティブオブジェクトにはサーキットブレーカの状態機械が付き、Normal、BrokenL1、BrokenL2、Safe、Recovering の五状態を持つ。回復条件は冷却時間、水位の持続的な低下、プローブ成功、連続ヘルスウィンドウとして明確化され、サンプルには安全監督器の完全な実装例が示されている。

RT-Thread にとっての意義はアプリケーション層の方法論にある。エコシステムの多くのプロジェクトではスレッドとメッセージキューの上に直接ロジックを積み、状態機械は switch を手書きすることが多く、有界・可観測・回復可能を同時に制約する枠組みが欠けている。この実装はクリティカルセクションを注入インターフェースとし、RT-Thread 側では割り込み禁止、FreeRTOS 側ではタスククリティカルセクションに ISR マスクを加える。ISR パスはロックを取らず libatomic にも依存せず、シングルコア MCU を明確な設計点としている。

5. 本期のトレンドとまとめ

5.1 トレンド：攻撃面はシステムコール引数からデバイスファームウェアへ移る

本期の 24 時間でメインリポジトリには 3 件がマージされ（#11955、#11978、#11891）、新規提案が 1 件（#11986）、新規欠陥が 1 件（#11985）である。数は前期より少ないが、三つの線にそれぞれ実質的な変化がある。

第一の線は、セキュリティ側で攻撃面が変わったことである。最近数期が報じていたのは、システムコール層の「値からオブジェクト」への検証欠如、すなわち getaddrinfo のネストしたユーザポインタ、pipe の ioctl ポインタ、timerfd が任意の fd を受け付ける問題、POSIX timer の id 越境、ブロックデバイス区画の生ポインタである。これらの欠陥の前提は「非特権プロセスが存在すること」であった。本期の MSI-X 欠陥は、前提が「悪意あるデバイスが挿入されること」に変わった：デバイスファームウェアが提供する読み取り専用設定レジスタをカーネルが信頼できる入力として扱い、BIR が 1 ビット越境するだけで rom メンバへ別名参照され、さらにはマッピング基底アドレスを任意の物理アドレスに変えてしまう。そのため CVSS は 6.8 にとどまるが、結果は同じく起動段階でのカーネル任意書き込みである。RT-Smart 以外でも、PCI フレームワークは MCU 上でも同様に影響を受け、これはデバイス側の入力検証がシステムコールよりも精査の少ない領域であることを示している。

第二の線は対応速度である。01:12 の報告、07:21 の提案で、六時間である；前期のブロックデバイス区画は 10 月 29 日の報告、11 月 3 日の提案で、五日であった。報告者は PoC、GDB ログ、バージョン追跡を備えた完全な資料を提供しており、メンテナは受け取れば直接修正できる。これはどのようなプロセス規定よりも修正時間を短縮する。代償としてレビュー負荷が後ろに圧し掛かり続け、キューには依然として四件が審査待ちである。

第三の線は、バージョン治理が初めて文書として形になったことである。751 行のバージョン番号とリリースプロセスは、Z を月次、Y を三から六か月、X を不定期と明記し、さらに Z は新規公開 API を導入してはならないこと、リリース後に元の Tag を変更してはならないこと、Y の周期はバージョン目標に書き込むことを規定している。下流のディストリビューションや商用バージョンにとって、これは一度のアップグレードを追随すべきか、どれだけの移行コストがかかるかを判断する直接の根拠となり、リリースノートの口頭の約束より信頼できる。

エコシステム側では、相反する二つの動きが注目に値する：一方はコミュニティが RT-Thread を FreeRTOS しか提供しない新チップ（ESP32-S31）に組み込み、コンポーネント形式でカーネルを置き換えつつベンダの無線スタックを保持する；他方は coact のような C++ フレームワークがアクティブオブジェクトと階層状態機械の成熟したパラダイムを RT-Thread のアプリケーション層に持ち込む。一方はカーネルのプラガブル性を検証し、他方はアプリケーション層の方法論を補う。イベント側では、睿擎デスクペットが「ボード側のリアルタイム IO と PC 側推論」の最小再現可能サンプルを提供しており、烏鎮の「新光」稿のハイブリッド配置の語りと同じ線にある。

5.2 制限と重複排除の説明

フォーラム club.rt-thread.org は本期も 468 を返し、WAF チャレンジページが前置され、スレッド一覧と本文は読み取れない。コミュニティ討論側の情報ギャップは GitHub とメディアコラムで補完した。公式ニュースインターフェースと公式サイトのニュース一覧はいずれも 6 月 17 日で止まっており、本期の新規はない。電子工程専輯のコラム集約ページは直リンクがタイムアウトし、睿擎デスクペットの一件は Google News でタイトルをヒットさせた後、元記事ページを取得して照合したもので、公開時期と本文はいずれも元ページによる。

GitHub 側は本期、匿名インターフェースの割り当てが十分で、組織レベルの核查は 35 リポジトリをカバーした。期間内にプッシュがあったのはメインリポジトリのみで、packages、env、rtthread-nano、sdk、smart-build、UtestRunner などの重点リポジトリはいずれもコミットがない。リポジトリ検索 topic:rt-thread は 8 件ヒットし、2 件を収録した（ESP32-S31 移植、coact）。残りは汎用 GUI プロジェクトまたは個人フォークである。

重複排除：#11978 は前期に提案状態として已閉環と記載したが、本期は実際のマージ時間に基づいて追記し、根因の詳細を示した；#11981、#11954、#11971、#11983 は前期に既出のため、本期は状態変化のみを記し、重複して展開しない；#11985 と #11986 は本期新規の一本の完全な連鎖で、欠陥と提案を二件に分けて記す。未収録：zlgopen/awtk のプッシュは汎用 GUI の改良に属し、RT-Thread との特段の関係はない；WorkerHMan/imx6ull_rt-thread と JiaVerso/myPilot_board は調査の結果、いずれも RT-Thread 本線の完全なフォークで独立したアプリケーションコードを持たないため、エコシステム項目としては扱わない；10 月 30 日のダブルイレブン販促稿は宣伝コンテンツに属し、すでに期間外である。

付録：情報源チェック表と情報源リスト

情報源チェック表

情報源 チェック結果
公式ニュースインターフェース（rt_org） 24時間で新規追加なし、最新項目は2026-06-17で停止
公式サイトニュース一覧 トップページのニュース欄は依然6月のまま、新規追加なし
コミュニティフォーラム 前置WAFチャレンジページ（HTTP 468）、一覧と本文が読み取り不可
メインリポジトリ commits 調査期間内に3件、11-04 10:44と21:30から21:33に集中
メインリポジトリ PR マージ3件（#11955、#11978、#11891）、新規作成1件（#11986）
メインリポジトリ Issue 新規作成1件（#11985）、PCI MSI-Xデバイス側入力が未検証
メインリポジトリ releasesとtags 新規追加なし、最新は依然v5.3.0（2026-09-10）
RT-Thread orgリポジトリ 35リポジトリをチェック、メインリポジトリのみ調査期間内にプッシュあり
GitHubリポジトリ検索 topic:rt-thread 8件、収録2件（ESP32-S31移植、coact）
Google News 中国語 3日以内の3件はすべて調査期間前に既報またはプロモーション。7日検索で睿擎デスクトップペット1件がヒット、収録済み
Google News 英語 有効なヒットゼロ、無関係なHackerNoon記事1件のみ
HN Algolia 7件すべてThreadネットワークプロトコル、求人または無関係な内容、除外済み
電子工程専輯公式コラム 11-04に睿擎デスクトップペット記事1件、収録済み
楽鑫公式発表稿 ESP32-S31の仕様と発表時期の照合に使用

完全な情報源リスト