調研視窗：2026-11-03 08:00 ~ 2026-11-04 08:00（北京時間，24 小時）

信源：RT-Thread 官方新聞介面與官網新聞列表、GitHub 主倉庫 commits / PR / Issue / releases / tags、RT-Thread org 十三個重點倉庫 Atom 提交流、GitHub 倉庫檢索（rt-thread 關鍵詞與 topic:rt-thread）、Google News 中英文六組查詢（走代理）、HN Algolia、電子工程專輯 RT-Thread 官方專欄、世界網際網路大會官網與網信辦通稿、鳳凰網商業新聞、club.rt-thread.org 論壇（本期仍受站點 WAF 限制）

本期索引

  • 一、核心與版本動態
    • getaddrinfo 的巢狀使用者指標加固合入：一次快照取代分層校驗（11-03）
    • DM365 的 SPI 分頻器除零，max_hz 傳 0 就觸發（11-03）
    • mailbox 用例第二次跑必掛：四個完成標誌從不清零（11-03）
    • 宏註釋寫行尾還是寫上方：編碼規範補了一節判據（11-03）
  • 二、安全跟進與待合併佇列
    • timerfd 接受任意 fd：兩個系統呼叫換到核心 PC 控制（11-04）
    • POSIX timer 的 id 不校驗，RT-Smart 上能改寫控制檯裝置（11-03）
    • 塊裝置分割槽 ioctl 的任意核心寫等到了提案（11-03）
    • 佇列：pipe 補丁仍在改，五筆舊賬繼續掛著（11-03）
  • 三、官方與社群活動
    • 烏鎮「新光」：AIOS 底座入選，講的是虛擬化混合部署（11-02 ~ 11-03）
    • 開源 AIOS 聯盟談小型具身智慧，RT-Thread 講三類 Agent 方案（11-03）
    • 官方新聞介面仍停在 6 月，釋出出口繼續在媒體專欄（11-04）
  • 四、生態與廠商適配
    • 野火 HPM6750 BTB 的 Studio BSP 上到 GitHub，把安裝流程寫成五步（11-04）
    • 新唐 N9H30 的社群 BSP：HMI 平臺的 ARM926EJ-S 老將（11-03）
    • 雙 MCU 消殺裝置：M7 管運動、M3 管噴灑，兩邊都跑 RT-Thread（11-03）
  • 五、行業應用
    • RV32IM 雙發射 FPGA CPU 把 RT-Thread Nano 接進 CoreMark 驗證鏈（11-03）
  • 六、本期趨勢與總結
    • 趨勢：安全側從報告走到提案，測試側從清單走到程式碼
    • 侷限性與去重說明

一、核心與版本動態

1.1 getaddrinfo 的巢狀使用者指標加固合入：一次快照取代分層校驗（11-03）

日期：2026-11-03 09:04（合入時間）　來源：提案 #11977

上一期報過的那筆維護者重做，視窗開頭合入，57 行新增、17 行刪除，只改網路系統呼叫目錄下的 syscall_netdb.c 一個檔案。

原實現的漏洞是分層校驗：只檢查了使用者傳入的頂層 res 緩衝區，隨後透過 res->ai_addr 這個使用者可控的巢狀指標寫入解析出來的 socket 地址，在 Smart/MMU 構建下等於把一次 getaddrinfo() 變成任意核心寫。hints 的欄位在頂層校驗透過之後仍從使用者記憶體直接讀，中間留著一個 TOCTOU 視窗。servname 的複製返回值判斷也寫錯了——拿 size_t 與 0 比較，恆為假。

改法是用 lwp_get_from_user() 把 res 與 hints 一次性拷進核心臨時結構體，之後所有巢狀指標都來自這份已校驗的快照；巢狀 sockaddr 與外層 addrinfo 統一用 lwp_put_to_user() 寫回，目標地址範圍由現有 helper 校驗，核心不再解引用未檢查的使用者指標。順帶按 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 用例第二次跑必掛：四個完成標誌從不清零（11-03）

日期：2026-11-03 10:53（合入時間）　來源：提案 #11963、缺陷 #6565

11 行新增，只改 src/utest/mailbox_tc.c。

現象是同一次啟動裡第二次執行 core.ipc_mailbox 必然失敗：第一次透過，第二次在接收執行緒裡觸發斷言 rt_object_get_type(...) == RT_Object_Class_MailBox 失敗，位置在 _rt_mb_recv() 第 2884 行。根因是四個 *_thread_finish 標誌只由工作執行緒置 1，從來沒有清過；第二次執行時測試體的等待迴圈 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 列——成組的常量宏是故意保持列對齊、接受超長的。所以判據不是行長，而是「需要多少說明」：一條註釋能說清就放行尾，需要一段話才能說清（帶引數的宏，要描述入參、展開結果與使用限制）就放上方加 @def。

文件還補了一條實踐差別：開啟 MACRO_EXPANSION 後，行尾 /**< 掛在宏的展開點上，同一宏多處展開時註釋位置可能出乎意料；上方塊註釋始終繫結定義處。因此頻繁展開的宏優先用上方塊註釋。示例全部取自倉庫真實程式碼（kerrno.h 的錯誤碼組、rtdef.h 的 RT_ALIGN），不是編的。

二、安全跟進與待合併佇列

2.1 timerfd 接受任意 fd：兩個系統呼叫換到核心 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 連線消失或 shell 停擺。軟體基線同為 v5.4.0-dev，引入提交是 077e9841，首個受影響版本 v5.0.2。

2.3 塊裝置分割槽 ioctl 的任意核心寫等到了提案（11-03）

日期：2026-11-03 15:51（提案時間）　來源：提案 #11981、缺陷 #11952

19 行新增、5 行刪除，只改一個檔案，作者 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 的判空，並把 lwp_user_mm.h 的 include 用 ARCH_MM_MMU 包住。

佇列裡另外五筆的狀態：cromfs 目錄名邊界（#11911）、poll 與 epoll 計數乘法迴繞（#11954）、9pfs 客戶端信任服務端長度（#11918）、DHCP 地址池耗盡後的無界搜尋（#11947）、signalfd 關閉時的監聽器摘除（#11935），本期均無合入。昨日合入的 #11978（GPT 分割槽首尾顛倒）已閉環。

三、官方與社群活動

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 講三類 Agent 方案（11-03）

日期：2026-11-03 17:14（報道時間）/ 2026-10-23（活動時間）　來源：鳳凰網：開源AIOS聯盟集結 WTCC 2026

一篇 11-03 才發出的商業新聞稿，寫的是 10 月 23 日上海西岸國際科技消費嘉年華（WTCC 2026）期間的「Jishu 創客坊：小型具身智慧方案研討會」。主辦方是安謀科技旗下極術社群，同臺的是「開源 AIOS 聯盟」三傢伙伴：瑞芯微、瑞莎計算機、RT-Thread。

安謀科技今年 7 月發起這個聯盟，聚焦持續感知、自主執行、長期記憶等能力，同期推出 JishuFriends 與 JishuBuddy 兩個落地成果：前者首款原型機 Puppy 以機器狗為載體，融合環境感知、語音視覺互動與自主移動；後者是面向 Agentic AI 的硬體開發工具，以自然語言為入口，適配 Arm 架構嵌入式裝置，並能基於模擬環境聯動真實具身裝置。

RT-Thread 出場的是 AI 資深工程師鄭煒，講的是機器狗、HyperCar 與 Codex 編排三類 Agent 方案，落點是把智慧體從「對話」推到「執行」，並明確 RT-Thread 將以具身智慧專案為重點、與安謀科技協力把 Agent 能力接到真實應用上。三傢伙伴的分工也在這篇稿裡比較清楚：瑞芯微講主控 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 官方專欄更新一篇（11-03 的烏鎮「新光」稿），此前的 11-01 雙十一促銷稿屬推廣內容，未收錄。論壇 club.rt-thread.org 仍返回 468 並前置 WAF 挑戰頁，帖子列表與正文無法直接讀取，社群討論側只能靠 GitHub 與媒體專欄交叉核驗。

四、生態與廠商適配

4.1 野火 HPM6750 BTB 的 Studio BSP 上到 GitHub，把安裝流程寫成五步（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）。

安裝流程被寫成五步：從 Releases 下載 BSP ZIP，在 Studio 的 SDK 管理器裡安裝資源包，新建工程時選 HPM6750-FIRE-BTB，在 RT-Thread Settings 裡勾外設，編譯後經 USB、DAPLink 或 J-Link 下載。這套寫法與先楫官方那批 BSP 倉庫是同一套模式，只是維護者從晶片原廠換成了個人。

值得記的是這類倉庫的出現頻率。昨天報過先楫半導體十三分鐘內把 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 分擔」的工程取捨：運動控制要實時性，噴灑與餘量監測是慢變數，拆開之後兩顆晶片各自都能留出餘量，通訊成本用一條串列埠協議就夠。

五、行業應用

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 與定時器中斷，主執行通道加一條整數副通道，支援符合條件的雙指令配對；前端有 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.1 趨勢：安全側從報告走到提案，測試側從清單走到程式碼

本期 24 小時裡主倉庫合入 4 筆（#11977、#11973、#11963、#11957），新建提案 4 筆（#11979、#11981、#11982、#11983），新建缺陷 2 筆（#11980、#11984）。數量與上期持平，但結構變了：上期是清積壓，本期是開新賬加補基礎設施。

第一條線是安全側的兩筆新報告，形狀高度一致——都是「描述符或識別符號未做型別校驗」。timerfd 不檢查 fd 是不是 timerfd，POSIX timer 不檢查 id 是否越界，兩個入口都把使用者給的值直接當成指向核心物件的入口。加上上期的圖形負偏移（使用者給的偏移不校驗符號）與 pipe（使用者指標不校驗），四筆可以歸為同一類：RT-Smart 的系統呼叫層在「值 → 物件」這一步缺少統一校驗。這類缺陷的修法都不復雜，難的是找出所有入口。

第二條線是響應速度在變快。#11952 是 10 月 29 日報告的塊裝置分割槽任意寫，11 月 3 日就有了提案 #11981；昨天的 getaddrinfo 重做（#11977）今天合入；pipe 補丁在佇列裡持續更新。報告、提案、維護者重做、合入這四段現在能在幾天內走完，與上期「報告多、補丁少」的判斷相比是明確變化。代價是評審壓力轉移到了維護者一側——佇列裡仍有五筆在審，每筆都需要有人讀懂復現步驟。

第三條線是 Z 版本的測試清單開始產出程式碼。上期報的 #11972 把「Z 版本能不能發」拆成逐框架的 QEMU 與 utest 清單，本期就出現了三筆直接引用它的提案：SPI 的韌體內虛擬迴環匯流排（#11979）、I2C 框架的模擬匯流排 utest（#11982）、以及給自動執行加迴圈與記憶體取樣的 #11983（這筆是 #11963 的後續，解決「只跑一次發現不了記憶體洩漏」）。配合今天合入的 mailbox 用例可重複執行，CI 側的測試底座在往「可重複、可觀測」走。

生態側兩條相反方向的動作都值得看：一邊是晶片原廠把 BSP 倉庫指令碼化批次釋出（先楫昨天的 12 倉同版本），一邊是個人開發者為野火 HPM6750 BTB 這類第三方板卡補 Studio BSP、為新唐 N9H30 這類老平臺補社群 BSP。廠商保證板間一致，社群填補長尾覆蓋，這兩頭合起來才是 RT-Thread 的板級生態全貌。

活動側，烏鎮「新光」是本期分量最重的一條：國家級平臺把「異構融合端側智慧AIOS底座」列入 35 項推介產品，敘事從「實時控制底座」轉向「端側智慧作業系統」，落點是機器人「大腦」與「小腦」協同。同一天出現的 WTCC 聯盟稿正好是這套敘事在具體場景裡的版本——三類 Agent 方案、與安謀科技的分工、以具身智慧為重點。宣傳與工程在同一條線上，這在以往的活動稿裡不多見。

6.2 侷限性與去重說明

論壇 club.rt-thread.org 本期仍返回 468 並前置 WAF 挑戰頁，帖子列表與正文無法讀取，社群討論側的資訊缺口由 GitHub 與媒體專欄補齊。官方新聞介面與官網新聞列表均停在 6 月 17 日，官網新聞模組本身載入失敗。

GitHub 匿名介面限額（每小時 60 次）在採集後段耗盡，組織級全量推送改用十三個重點倉庫的 Atom 提交流核查（packages、env、rtthread-nano、sdk、smart-build、UtestRunner、userapps 等），視窗內均無提交，僅主倉庫有推送。缺陷 #11950 只取到標題與摘要，未讀正文；#11984 與 #11980 的 PoC 細節全部引自報告正文，未做獨立復現，報告中已按原文限定條件表述（QEMU 型號、基線提交、受影響版本）。

Google News 中文側三日內 5 條命中，收錄 2 條（烏鎮「新光」、WTCC 聯盟稿），雙十一促銷稿屬推廣且超出視窗、未收錄，上海開源大賽稿上期已報。英文側兩組查詢零命中。HN Algolia 視窗內 5 條全部是 Thread 組網協議、招聘看板與 Mbed TLS 維護，與本主題無關，已剔除。

去重：昨日報過的 #11977 提案本期合入，按「進展」處理並記為條；#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 重點倉庫 十三個倉庫 Atom 核查，視窗內均無提交
GitHub 倉庫檢索 新增 2 個 RT-Thread 相關倉庫（HPM6750 BTB BSP、N9H30 BSP），topic 命中 3 個
Google News 中文 3 日內 5 條，收錄 2 條（烏鎮新光、WTCC 聯盟稿）
Google News 英文 零命中
HN Algolia 5 條均為 Thread 協議或招聘內容，非本主題
電子工程專輯官方專欄 11-03 一篇烏鎮稿，已收錄
世界網際網路大會官網 / 網信辦 博覽會開幕與 35 項「新光」口徑，用於核對官方稿

完整信源清單

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