调研窗口：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 项「新光」口径，用于核对官方稿

完整信源清单