调研窗口：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 中英文五组查询（走代理）、HN Algolia、电子工程专辑 RT-Thread 官方专栏、乐鑫官方发布稿、club.rt-thread.org 论坛（本期仍受站点 WAF 限制）

本期索引

  • 一、内核与版本动态
    • 版本编号与发布流程第一次成文：Z 版本按月、Y 版本 3 至 6 个月（11-04）
    • 串口 TIOCGWINSZ 改成直接问设备：不再借 tshell 读字符（11-04）
    • GPT 分区首尾颠倒补上校验：下溢出的巨型分区不再注册（11-04）
  • 二、安全跟进与待合并队列
    • MSI-X 表的 BIR 与偏移不校验，恶意 PCIe 设备在探测阶段写任意物理地址（11-05）
    • 报告后 6 小时出修复提案：五项校验一次补齐（11-05）
    • 队列：块设备分区补丁又有更新，四笔继续挂着（11-05）
  • 三、官方与社区活动
    • 睿擎 RK3576 桌宠：板子管听和说，PC 管想（11-04）
    • 官方新闻接口仍停在 6 月，媒体专栏是唯一稳定出口（11-05）
  • 四、生态与厂商适配
    • ESP32-S31 上把 RT-Thread 塞进 ESP-IDF：36 项自检全过（11-04）
    • coact：一份头文件同时接 RT-Thread、FreeRTOS 和 Linux（11-04）
  • 五、本期趋势与总结
    • 趋势：攻击面从系统调用参数挪到设备固件
    • 局限性与去重说明

一、内核与版本动态

1.1 版本编号与发布流程第一次成文：Z 版本按月、Y 版本 3 至 6 个月（11-04）

日期：2026-11-04 10:44（合入时间）　来源：提案 #11955、议题 #11956

751 行新增、14 个文件，全部是文档：中英双份的《版本编号制定与实施细则》与《版本发布流程》，配 7 张流程图，并登记进 Doxygen 索引，会随文档中心一起发布。作者 kurisaW，10 月 30 日提出，本窗口开头合入。文档自身标注版本 1.0、日期 2026-10-27。

规则的核心是把版本节奏写成数字：Z 修订版本原则上每月一个，Y 次版本按功能积累与维护资源每 3 至 6 个月一个，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 发布前约一个月进入修复收敛，Y 发布前约一个月进入功能收敛并冻结 X.Y；正式发布后发现问题只能发 X.Y.Z+1，不得修改原 Tag、原 Release 内容或原交付物；改变默认行为或资源占用的 Y、Z 版本必须在 Release 里写明。配套的《版本发布流程》把一次发布拆成六个阶段——版本准备、制定下个版本初步目标、开发准备、开发、预发布、发布，预发布部分含特性收敛、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.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，把低三位当 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 且不写入。

队列里另外三笔的状态：poll 与 epoll 计数乘法回绕（#11954）11-05 00:04 更新；pipe ioctl 用户指针加固（#11971）11-04 14:57 更新；给自动运行加循环与内存采样的 utest 提案（#11983）11-04 12:44 更新，三笔均为待审。前一期合入的 #11978 已在本期闭环，#11977、#11973、#11963、#11957 均已闭环，积压没有继续变厚。

三、官方与社区活动

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 不开机它就哑了。

一轮对话被拆成七步：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 出声，同时按响应头里的表情标记切帧。

为什么中间要加一层桥，文章给了两个具体理由：api.deepseek.com 只有文本接口，没有 /v1/audio/ 系列端点，板端直连拼不出语音链路；会话连续性要求固定 DSH_SESSION_ID，语音若新开一档，人设与上下文全变。桥是阻塞的，板端 curl 带 180 秒超时，从按键一直挂到音频回传。

三个坑写得比结论有价值。其一，一次按键跑了两轮对话——守护进程被杀时子进程不一定跟着死，两个进程同时读同一个 event7，补的办法是 flock 单实例、EVIOCGRAB 独占设备、启动时按 /proc 的 fd 清掉孤儿进程，三个缺一个就能复现。其二，流式 TTS 会截断，代码里 DSH_VOICE_TTS_SSE 开关默认关着，注释直接写 often truncates，早期拿到第一段就合成，一句话只有 10 KB，改成「连续多次轮询内容不变且口播至少两个汉字」才合成，体积到 115 KB。其三，表情分两档优先级，idle、listening、speaking 为 0，情绪为 1，1 锁住时 0 的请求直接忽略，锁到期必须自动回 idle，否则播完 confused 会停在最后一帧。

这条的价值在于它把「实时 IO 留在板端、推理放到算力更强的一侧」写成了可复现的七步链路，与乌镇「新光」稿里 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 账号更新一篇睿擎桌宠稿，已收录。论坛 club.rt-thread.org 仍返回 468 并前置 WAF 挑战页，帖子列表与正文无法直接读取，社区讨论侧只能靠 GitHub 与专栏交叉核验。

四、生态与厂商适配

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/ 直接 drop-in 到 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 与引脚中断、三路 I2C、SPI（轮询，非完整总线框架）、两路 17 位 ADC、八路 LEDC PWM、MCPWM 互补与死区、四路 GPTimer、PCNT、RMT、TWAI 均已接；无线侧 Wi-Fi 2.4 GHz 能连接并拿到 IP、能扫描，BLE 控制器加 NimBLE 可用；未移植的是 I2S、SD/MMC、LCD、摄像头、触摸、以太网、硬件加密与低功耗。

上板结果是 36 项自检全部通过、0 失败，双核都在跑线程，Wi-Fi 在双核开启的情况下能连上并拿到 IP。文章里三个非显然的设计点值得记：CONFIG_FREERTOS_UNICORE=y 与「双核」并不矛盾，这两个宏描述的是 FreeRTOS 是否在多核上调度，设成 y 后 IDF 不调用 start_other_core，第二个核留给 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、蓝牙 5.4、802.15.4，官方软件栈是 ESP-IDF 加 FreeRTOS。这个项目把内核换掉而保留 IDF 的无线固件与驱动，等于在厂商只提供一种 RTOS 的芯片上验证了另一种内核的可插拔性。定位写得诚实：host 与多架构移植只是测试参考，产品目标仍是单核 MCU。

4.2 coact：一份头文件同时接 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、没有动态注册，最坏 flash 与 RAM 占用在链接期就能确定，仓库自带 Renode 下的占用脚本。可检测：提交结果用 SubmitResult 返回码，另有 Monitor 计数、Breaker::level() 与 fatal_assert 处理，失败能在发生处看到属于哪个主动对象、哪个分区。可恢复：每个主动对象配一个断路器状态机，Normal、BrokenL1、BrokenL2、Safe、Recovering 五态，恢复条件明确为冷却时间、水位持续偏低、探测成功、连续健康窗口，示例里给了安全监督器的完整写法。

对 RT-Thread 的意义在应用层方法论。生态里多数项目直接用线程加消息队列堆逻辑，状态机往往手写成 switch，缺一个把有界、可观测、可恢复一起约束住的框架；这份实现把临界区做成注入接口，RT-Thread 侧用关中断，FreeRTOS 侧用任务临界区加 ISR 屏蔽，ISR 路径不加锁也不依赖 libatomic，单核 MCU 是明确的设计点。

五、本期趋势与总结

5.1 趋势：攻击面从系统调用参数挪到设备固件

本期 24 小时主仓库合入 3 笔（#11955、#11978、#11891），新建提案 1 笔（#11986），新建缺陷 1 笔（#11985）。数量比上期少，但三条线各有实质变化。

第一条线是安全侧换了一个攻击面。最近几期报的都是系统调用层的「值到对象」缺校验：getaddrinfo 的嵌套用户指针、pipe 的 ioctl 指针、timerfd 接受任意 fd、POSIX timer 的 id 越界、块设备分区的裸指针。这些缺陷的前提都是「有一个非特权进程」。本期的 MSI-X 缺陷前提换成了「插进来一个恶意设备」：设备固件提供的只读配置寄存器被内核当成可信输入，BIR 越界一位就别名到 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 项目或个人 fork。

去重：#11978 上期按提案状态写成已闭环，本期按实际合入时间补记并给出根因细节；#11981、#11954、#11971、#11983 上期已列，本期只记状态变化，不重复展开；#11985 与 #11986 是本期新开的一条完整链路，缺陷与提案分两条记。未收录：zlgopen/awtk 的推送属通用 GUI 改进，与 RT-Thread 无专项关系；WorkerHMan/imx6ull_rt-thread 与 JiaVerso/myPilot_board 经查都是 RT-Thread 主线的完整 fork，没有独立的应用代码，不作为生态条目；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 日查询命中 2 条，11-04 睿擎桌宠已收录，10-30 直播预告已出窗口
Google News 英文 零有效命中，仅一条无关的 HackerNoon 稿
HN Algolia 7 条全部为 Thread 组网协议、招聘或无关内容，已剔除
电子工程专辑官方专栏 11-04 一篇睿擎桌宠稿，已收录
乐鑫官方发布稿 用于核对 ESP32-S31 规格与发布时间

完整信源清单