調研視窗：2026-10-22 08:00 ~ 2026-10-23 08:00（北京時間，24 小時）

信源：RT-Thread 官方新聞介面、社群論壇文章介面、GitHub（主倉庫 commits / PR / Issue / Releases / tags、RT-Thread-packages 組織各倉、topic:rt-thread 生態檢索）、Google News 聚合（中英文多組查詢，走代理）、HN Algolia、行業媒體與廠商渠道核驗（詳見附錄信源清單）

本期索引

  • 一、核心與版本動態
    • RISC-V 票號自旋鎖改用 AMO：放鎖側不再走 LR/SC 重試，K1 的 SMP 配置同時由 4 核開到 8 核（10-22）
    • 訊息佇列 FIFO 被高優先順序執行緒插隊：掛了兩年的舊單給出可在主線穩定復現的最小例（10-22）
    • 主線結束三日零提交：視窗內落地 4 筆提交、3 個提案合入，v5.4.0 仍只有版本宏（10-23）
  • 二、安全與穩定性跟進
    • NVMe 每遇一個非活動名稱空間漏 4480 位元組：合規盤每次啟動即丟掉約 1.1 MB 核心堆（10-23）
    • 9PFS 直接採信服務端長度欄位：ASAN 越界讀穿 8.3 MB 接收緩衝，修復提案已開（10-22）
    • NFS 越界寫缺陷單狀態未變，本期無認領也無修復提案（10-22）
  • 三、官方與社群活動
    • 官方新聞介面仍停在六月，社群文章視窗內無全新長文（10-23）
  • 四、生態與廠商適配
    • ESP32-C3/C6 的 ESP-IDF v6.1 適配合入主線：RISC-V 工具鏈一併跳到 GCC 15.2（10-22）
    • GD32VW553 進入 at_device 包：RISC-V 的 Wi-Fi 6 加 BLE 5.2 晶片可 menuconfig 直接選配（10-22）
    • GD32EmbeddedUI 示例建倉一天後進 LVGL 包索引，包與倉庫形成閉環（10-22）
    • scons –attach 在中文 Windows 上直接崩：4 處 emoji 標記換成 ASCII（10-22）
  • 五、總結與趨勢觀察
    • 本期趨勢
    • 侷限性與去重說明

一、核心與版本動態

1.1 RISC-V 票號自旋鎖改用 AMO：放鎖側不再走 LR/SC 重試，K1 的 SMP 配置同時由 4 核開到 8 核（10-22）

日期：2026-10-22 17:59（合入時間）　來源：PR #11904、cpuport.c、K1 BSP README

這次改動落在 libcpu/risc-v/common/cpuport.c，把票號鎖（ticket spinlock）的加鎖與放鎖兩條路徑分別換掉了實現。原先是兩側都用 LR/SC 迴圈對同一個字做「讀—改—寫」：加鎖側把高 16 位的下一票號加一、與低 16 位的當前持鎖號拼回一個整字再寫回；放鎖側同樣走 LR/SC 把持鎖號加一。改動後的註釋點明瞭兩種失敗面：其一，取票路徑與一條正在重試 LR/SC 的放鎖路徑會在同一保留集上互相打斷，在高核數爭用下陷入活鎖，這正是標題裡的 SMP 停頓；其二，放鎖用整字讀改寫會把併發期間新領走的票號一起覆蓋掉。

修法是把取票改成 amoadd.w.aqrl 單指令原子加（AMO 不會失敗，也就不存在重試被打斷的問題），票號增量取 1 << 16，兩個 16 位計數器仍然共處低 32 位——註釋特意寫明這一點在 RV64 上同樣成立，因此用的是 32 位寬的 amoadd.w 而非 amoadd.d。放鎖側則徹底去掉原子讀改寫：只有持鎖者會寫持鎖號，用一次 16 位半字儲存做「加一」即可，既保留了併發新領的票號，也免掉 LR/SC；兩側各補一處 rt_hw_barrier()，保證臨界區訪存排在觀察到對方釋放之後、以及在推進持鎖號之前完成釋出。

同一提案把 bsp/spacemit/k1 的 CONFIG_RT_CPUS_NR 與 rtconfig.h 的 RT_CPUS_NR 由 4 改為 8，並在 K1 的兩個 README 與 bsp/README.md 的支援矩陣裡補上說明，屬「先修鎖、再放開核數」的順序。按 K1 現行 README，該 SoC 為 64 位 RISC-V、整合 8 個 X60 核心並帶向量擴充套件，BSP 走裝置樹、由 U-Boot/OpenSBI 引導在 S 模式執行，驗證平臺是 Banana Pi BPI-F3。整個提案 6 個檔案 +33/-37，改動量不大但觸及 RISC-V 多核的基礎設施。

1.2 訊息佇列 FIFO 被高優先順序執行緒插隊：掛了兩年的舊單給出可在主線穩定復現的最小例（10-22）

日期：2026-10-22 13:54（評論時間）　來源：Issue #4940、ipc.c

2021 年 8 月的舊單在視窗內被重新推進。該單原指訊息佇列與郵箱在 RT_IPC_FLAG_FIFO 下無法保證先進先出，維護者當年的回覆承認「此處沒有做鎖定，而 semaphore 相當於做了鎖定」，此後一直未落地修法。新評論按這條線索補了一個最小復現，並宣告在主線上可穩定重現。

復現配置是 rt_mq_create() 建一個 msg_size=4、max_msgs=1、RT_IPC_FLAG_FIFO 的佇列：低優先順序執行緒（20）先做阻塞式接收、佇列為空因此掛在等待佇列首位；高優先順序執行緒（10）不進佇列等待，而是先阻塞在一個訊號量上；主執行緒發一條訊息，低優先順序執行緒被從等待佇列摘下、進入就緒佇列；主執行緒緊接著釋放訊號量，高優先順序執行緒就緒；主執行緒延時讓出 CPU 後，高優先順序執行緒先跑，用非阻塞接收把那條訊息取走。訊息沒有落到排在最前的等待者手裡，FIFO 語義被優先順序搶佔破壞。

問題的性質與 1.1 不同：不是競態視窗，而是「喚醒即出隊」的語義選擇——被喚醒者一旦離開等待佇列就成為普通就緒執行緒，此後任何更高優先順序的非阻塞取用都能合法地把它該拿的訊息拿走。評論裡提到 uClinux 的做法是喚醒但不出隊，等真正拿到鎖才從掛起佇列摘除，可作為修法參考。該單目前仍是開啟狀態，本期沒有對應提案。

1.3 主線結束三日零提交：視窗內落地 4 筆提交、3 個提案合入，v5.4.0 仍只有版本宏（10-23）

日期：2026-10-23（核查時間）　來源：主倉庫提交記錄、releases、tags

上一期記錄的主線靜止在視窗內被打破：10-22 一天落地 4 筆提交，全部由三個提案合入帶進，分別是 ESP32-C3/C6 的 ESP-IDF v6.1 適配（07:42 UTC）、RISC-V 票號鎖與 K1 八核（09:59 UTC 兩筆）、tools/attachconfig.py 的 emoji 替換（10:00 UTC）。合入時間集中在 15:42 到 18:00（北京時間）三個小時內，且均由同一維護者處理，呈現為一次集中的評審收尾。

版本側仍然沒有動作：最新發布物與標籤依舊是 09-10 的 v5.3.0，10-17 那筆「Bump version to v5.4.0」至今只有版本宏，沒有釋出說明、沒有二進位制、也沒有預釋出標籤。組織層面視窗內只有主倉庫與 packages 兩個倉有推送，其餘倉庫的最近活動時間與上期一致。

二、安全與穩定性跟進

2.1 NVMe 每遇一個非活動名稱空間漏 4480 位元組：合規盤每次啟動即丟掉約 1.1 MB 核心堆（10-23）

日期：2026-10-23 01:15（建立時間）　來源：Issue #11919、nvme.c

研究者 XueDugu 在視窗末尾提交 NVMe 驅動的核心堆洩漏。nvme_scan_device() 用 Identify Controller 回覆裡裝置可控的 nn（Number of Namespaces）作迴圈上界，在 1 到 nn 之間逐號探測，而每輪都會先 rt_calloc 一塊 4480 位元組的 rt_nvme_device，之後才發該號的 Identify 命令。兩條失敗路徑都不歸還這塊記憶體：nsze == 0（名稱空間已分配但未啟用，屬規範允許的正常回復）走 continue；Identify 命令出錯走 goto _free_res，跳過釋放。

影響面按作者實測給出：在官方 qemu-virt64-aarch64 BSP 的預設配置下，不接 NVMe 時空閒核心堆 66,941,784 位元組；接一塊 nn = 1 的單名稱空間盤為 66,931,592 位元組，屬正常；接 QEMU 原裝 nvme 裝置則降到 65,774,912 位元組——QEMU 始終上報 nn = 256 而只暴露 1 個名稱空間，這一回複合法，於是 255 個非活動號各漏 4536 位元組（含 memheap 頭），單次啟動即 1,156,872 位元組、約 1.1 MB，佔 64 MB 核心堆的 1.8%。熱插拔與重掃會線性累積；若裝置上報更大的 nn（如 0xFFFFFF），迴圈會在堆耗盡前一直分配，最終系統無法啟動，串列埠停在 hello rt-thread 之後不再出提示符。

作者給出 CWE-401 與 CVSS 3.1 4.9（Medium，AV:P），並說明「按次啟動的 1.1 MB 洩漏不需要攻擊者」，只有「堆耗盡致不可啟動」需要惡意或畸形控制器。缺陷由 2024-11-24 的提交 945114fd5（NVMe 支援，#9591）引入，v5.2.0 起的每個版本與當前主線均含。建議修法是把這塊分配挪到確認名稱空間有效之後、並在兩條失敗路徑補齊釋放，同時不要直接採信 nn 作上界（可按 mnan 設上限，或改用 CNS 02h 的 Active Namespace ID 列表）。該單目前未打標籤、未指派。

2.2 9PFS 直接採信服務端長度欄位：ASAN 越界讀穿 8.3 MB 接收緩衝，修復提案已開（10-22）

日期：2026-10-22 19:36（建立時間）　來源：PR #11918、Issue #11289、dfs_9pfs.c

dfs_9pfs_read() 與 dfs_9pfs_getdents() 存在與服務端回覆長度脫鉤的越界讀，提案 +58/-4 只動 dfs_9pfs.c 一個檔案。根因是 p9_transaction() 的返回位元組數被丟棄（傳入 RT_NULL），隨後程式碼直接使用報文裡的 count、每條記錄的 stat_size 與 name_len，從不與真正收到的資料量比對；伺服器只要回一個 count 巨大而實際很短的報文，解析器就會一路讀越接收緩衝。正常情況下被跳過的 . 記錄不會命中 fd->pos >= end 的退出條件，解析器因此可以持續前進。

作者用 bsp/simulator（x86-64、ASAN、-fsanitize=address）搭了一個假的記憶體 9P 伺服器：握手與 Tstat/Topen/Tclunk 正常應答，但對 Tread 只回 11 位元組報文、count 謊報約 2 GB，並在接收緩衝後方鋪滿偽造的 . 記錄加 ASAN 毒化守衛帶。修復前觸發 AddressSanitizer: use-after-poison，讀位置落在 8 MB 堆區之內第 8,334,515 位元組，程序 ABORT；修復後惡意回覆被拒（返回 P9_READ_UNEXPECTED_DATA 或 -EIO），正常目錄解析不受影響，hello.txt 與 subdir 兩項照舊列出。

修法四步：兩個函式都把實際接收位元組數傳入 p9_transaction() 並校驗不小於 P9_MSG_READ_DATA；count 收斂到 rx_size - P9_MSG_READ_DATA，不再採信報文值；getdents 逐記錄校驗剩餘位元組能否容納長度欄位、stat_size 是否越出剩餘資料、name_len 是否越出當前記錄；read 路徑同樣收斂實際讀到的位元組數（作者特別指出 got <= set 並不充分，因為 set 本身就可能超過接收容量）。補丁在最新 master 上 git apply --check 透過。

2.3 NFS 越界寫缺陷單狀態未變，本期無認領也無修復提案（10-22）

日期：2026-10-22（核查時間）　來源：Issue #11917

上一期收錄的 NFS 客戶端越界寫（nfs_read() 採信服務端 READ3resok.count 作 memcpy 長度，單次 cat 可越過 81 位元組棧緩衝）在視窗內只有狀態重新整理，仍處開啟且未指派，沒有出現對應修復提案。同一研究者在 24 小時內連續報出 NVMe 堆洩漏（2.1）與 9PFS 越界讀（2.2），三單的共性都是「裝置或服務端可控的後設資料被直接當作記憶體操作的長度或上界」，其中 9PFS 一單已帶可用的收斂式修法。按作者自述，此前 mtd-cfi（#11272）與 usbhost（#11287、#11288）屬同一族問題且已被接受，這條線索值得按族系統性排查，而不是逐單修補。

三、官方與社群活動

3.1 官方新聞介面仍停在六月，社群文章視窗內無全新長文（10-23）

日期：2026-10-23（核查時間）　來源：RT-Thread 官方新聞介面、社群論壇文章介面

官方新聞介面的組織分類本次返回 5 條，最新一條仍是 2026-06-17 的「阿布扎比投資論壇」，停更已逾四個月；官網新聞列表頁為前端動態渲染，抓取只得載入空殼，新聞資料以介面為準。社群文章介面前若干條的最新更新時間是 10-21 10:08 的「基於 NS800RT7P65 與 ESP32-C3 的雙板協同智慧終端」，該作品上一期已按編輯更新處理，本期無新變化。視窗內未見峰會、駭客松或大學計劃類新公告，亦無廠商渠道的新版本釋出稿。

四、生態與廠商適配

4.1 ESP32-C3/C6 的 ESP-IDF v6.1 適配合入主線：RISC-V 工具鏈一併跳到 GCC 15.2（10-22）

日期：2026-10-22 15:42（合入時間）　來源：PR #11870、RT-Thread-packages/esp-idf PR #18

上一期記錄為「阻塞解除、上板待驗」的主倉提案在視窗內正式合入。改動 55 個檔案 +4564/-333，分三塊：C3 與 C6 分別適配 ESP-IDF v6.1 的相容面（portmacro.h 的 FreeRTOS V11 宣告、sections.ld、port.c、main.c、rtconfig.py 及 ADC/SPI 驅動小改）；RISC-V 工具鏈從 gcc 11.2（esp-2022r1）升到 gcc 15.2（esp-15.2.0_20251204），同步改 CI workflow、docker 與 tools/ci；並明確把 FreeRTOS-Wrapper 的改動切出去另開提案。

合併時作者給出的驗證只有編譯層面：C3 十三個 attachconfig 配置在 gcc 15.2 加 esp-idf #18 包上全部透過，C6 預設配置編譯連結透過，硬體上板一欄寫的是「待驗證，C3 燒錄包已備好」。也就是說這是一次以構建透過為放行條件的合入。對 RISC-V 的意義在於 C3、C6 屬 RISC-V 核心（與 Xtensa 的 S2、S3 不同），配合已合入的包側 CONFIG_IDF_RTOS_RTTHREAD 開關，這條路徑現在從包到主倉都已就位，剩餘風險集中在上板。

4.2 GD32VW553 進入 at_device 包：RISC-V 的 Wi-Fi 6 加 BLE 5.2 晶片可 menuconfig 直接選配（10-22）

日期：2026-10-22 09:21（合入時間）　來源：RT-Thread-packages PR #2047、GD32VW553 產品頁

RT-Thread-packages 的 at_device 包新增 GD32VW553 一款，+68/-0，改動是 iot/at_device/Kconfig 加一行 source 與新增的 gd32vw553/Kconfig（67 行）。配置項覆蓋初始化方式（可選擇由執行緒非同步初始化）、是否啟用 AT socket、以及示例引數：網路裝置名預設 wifi0、SSID 與密碼、AT 客戶端裝置名預設 uart4、串列埠波特率預設 115200（範圍 9600 到 2000000）、接收行緩衝長度、復位引腳號與有效電平（-1 表示不做硬體復位）。

GD32VW553 是兆易創新 GD32V 系列裡的無線 MCU，按廠商產品頁為 RISC-V 核心、主頻最高 160 MHz，整合 2.4 GHz Wi-Fi 6（802.11b/g/n/ax，HT20）與 Bluetooth LE 5.2，片上 4 MB Flash 與 320 KB SRAM，並提供 DSP 硬體加速與雙精度浮點單元。把它做成 AT device 意味著 RT-Thread 側不直接驅動射頻，而是把模組當外掛網路裝置、經 AT 命令走 UART 接入，這與該包既有的 ESP8266、ESP32、EC20、SIM800C 等條目同一處理方式，屬低成本聯網路徑而非深度移植。

4.3 GD32EmbeddedUI 示例建倉一天後進 LVGL 包索引，包與倉庫形成閉環（10-22）

日期：2026-10-22 11:17（合入時間）　來源：RT-Thread-packages PR #2048、GD32EmbeddedUI-demos

上一期記錄的 GD32EmbeddedUI-demos 建倉（10-21，當時只有一筆 Initial commit）在一天後接進了包體系：LVGL 包新增 gd32embeddedui_demos 條目，+57/-0，含 multimedia/LVGL/Kconfig 一行 source、27 行子 Kconfig 與 29 行 package.json。至此該示例從「組織下新建的空倉」變成 menuconfig 裡可選的一個元件包，原始碼仍指向原倉庫，屬輕量的索引掛載而非程式碼複製。

同批還有兩筆包側更新：[multimedia/LVGL] Add GD32EmbeddedUI demos package（11:17）與 [at_device] Add GD32VW553 package configuration（09:21），作者相同，都在視窗內合入。把 4.2 與 4.3 合起來看，兆易創新這條線在 24 小時內同時補了「聯網」與「介面」兩個基礎件，節奏上更像在為一套完整方案鋪底，而非單點提交。

4.4 scons –attach 在中文 Windows 上直接崩：4 處 emoji 標記換成 ASCII（10-22）

日期：2026-10-22 18:00（合入時間）　來源：PR #11908、attachconfig.py

tools/attachconfig.py 的 4 行 print 裡用了 emoji 狀態標記，在中文 Windows 上會導致整條命令不可用。原因是 Python 的 stdout 編碼跟隨區域內碼表（簡體中文系統為 936/GBK），無法編碼 U+2705 與 U+274C，首次列印即拋 UnicodeEncodeError 並中止；由於 --attach=?、--attach=<name>、--attach=default 三種用法都走同一個函式，三條路徑一併失效。設 PYTHONIOENCODING=utf-8 可以繞過，但普通使用者不會知道。

修法把 4 處換成 [OK] 與 [ERR] 純 ASCII 標記，保留原有 ANSI 顏色碼——tools/env_utility.py 與 tools/ci/bsp_buildings.py 本就在用 ANSI 彩色輸出，屬既有約定。tools/ci/ 下的 emoji 未動，因為它們寫進的是 GitHub Actions summary 的 Markdown、由 UTF-8 渲染，不受控制檯編碼影響。改動只碰 4 行 print，不涉及邏輯，作者在 Windows 11 中文版預設內碼表 936 上做了修復前後對照，所用 BSP 是當前唯一帶 attachconfig.yml 的 ra6m3-hmi-board 目錄。這類問題不涉及核心，但對國內開發者的首次上手體驗影響直接。

五、總結與趨勢觀察

5.1 本期趨勢

  • RISC-V 多核路徑在同一天補了兩處基礎件：票號鎖從 LR/SC 雙向重試改為「取票用 AMO、放鎖用半字儲存」，把活鎖面從根上去掉，K1 隨即放開到 8 核；ESP32-C3/C6 則拿到 ESP-IDF 6.1 底座與 GCC 15.2 工具鏈。前者修的是多核正確性，後者修的是新底座可得性，兩者都屬「不顯眼但決定能跑多穩」的工作。
  • 主線從靜止轉為集中收尾：連續三日零提交後，10-22 三小時內合入三個提案、四筆提交。節奏上更像維護者攢了一批評審一次性處理，而不是開發強度回升；v5.4.0 至今只有版本宏，說明發布流程仍未啟動。
  • 「裝置或服務端可控的後設資料即長度」已成一條成族缺陷線：同一研究者在兩天內報出 NFS 越界寫、NVMe 堆洩漏、9PFS 越界讀三單，9PFS 已帶收斂式修法。作者自己把這條線追溯到 mtd-cfi 與 usbhost 的舊單，逐單修補的成本遠高於按族排查。
  • 中文 Windows 的編碼問題開始被當作可修缺陷：scons --attach 因 emoji 在 GBK 下拋異常而整條命令不可用，屬國內開發者高頻踩點。這類修復技術含量低但收益直接，值得與工具鏈其他 Windows 適配項一起看。
  • 兆易創新把無線與介面基礎件一起補：24 小時內 GD32VW553 進 at_device、GD32EmbeddedUI 示例進 LVGL 包，前者是 RISC-V 的 Wi-Fi 6 模組、後者是 UI 示例，指向的是成套方案而非單點提交。

5.2 侷限性與去重說明

  • 本期為 24 小時視窗（10-22 08:00 ~ 10-23 08:00），週五，非週一，不做多日合併。
  • 與上期去重：#11870 上期已收錄「阻塞解除、上板待驗」，本期只寫合入結果與合併時的驗證邊界；#11912、#11914、#11915、#11917、#11910、#11911 上期已收錄，本期只在狀態確有變化時提及（#11917 狀態未變，僅作一句說明）。
  • 行業應用（工業、車載、機器人、具身智慧）渠道在本視窗無新增報道：睿擎產品線自 V1.8.4 釋出後未見後續版本或落地案例，社群文章側亦無新的應用類長文，故本期不設該章。
  • 視窗內 Google News 英文與中文查詢均未返回 RT-Thread 相關有效稿，HN 檢索到的四條均為 threads 字面誤匹配（Brotli 執行緒池、iPhone 應用商店等），已按標題語義剔除，不作候選。
  • topic:rt-thread 生態檢索視窗內只有 zlgopen/awtk 一個倉有推送，該倉為通用嵌入式 GUI、提交與 RT-Thread 無專項關聯，按生態參考看待，未單列條目。
  • 組織層面視窗內僅主倉庫與 packages 兩倉有推送，其餘倉庫最近活動時間與上期一致；匿名介面限額下未做組織級全量推送核查，改用倉庫提交流、組織頁與 Atom 訂閱交叉驗證。
  • 官方新聞列表頁為前端渲染、抓取只得空殼，新聞資料以介面為準；社群文章介面只取前若干條，最新一條為上期已收錄作品的編輯更新。

附錄：信源核查表

信源 核查結果
RT-Thread 官方新聞介面（組織分類） 無新增，本次返回 5 條，最新仍為 06-17
官網新聞列表頁 前端動態渲染，抓取只得載入空殼
社群論壇文章介面 前若干條無全新長文，最新為上期已收錄作品的編輯更新（10-21 10:08）
GitHub 主倉庫 commits 視窗內 4 筆，終結 10-19 以來的三日零提交
GitHub 主倉庫 PR 視窗內 13 筆更新，合入 3 筆（#11870、#11904、#11908），新開 1 筆（#11918）
GitHub 主倉庫 Issue 新開 1 筆（#11919，NVMe 堆洩漏），舊單 #4940 獲最小復現
GitHub 主倉庫 releases / tags 無新發布，最新仍為 09-10 的 v5.3.0
GitHub RT-Thread-packages 合入 2 筆（at_device GD32VW553、LVGL GD32EmbeddedUI demos）
GitHub 組織其他倉庫 視窗內無推送，最近活動時間與上期一致
GitHub topic:rt-thread 生態檢索 僅 zlgopen/awtk，通用 GUI，非專項動態，未收錄
Google News 聚合（中英文，走代理） 視窗內無 RT-Thread 相關有效稿
HN Algolia 四條候選均為 threads 字面誤匹配，已剔除
行業媒體與廠商渠道 視窗內無新版本釋出稿或落地方案報道

完整信源清單

//www.gigadevice.com/product/mcu/wireless-mcus/gd32vw553-series>