调研窗口：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 字面误匹配，已剔除
行业媒体与厂商渠道 窗口内无新版本发布稿或落地方案报道

完整信源清单