Research window: 2026-11-03 08:00 ~ 2026-11-04 08:00 (Beijing time, 24 hours)

Sources: RT-Thread official news API and official website news list, GitHub main repository commits / PR / Issue / releases / tags, Atom commit feeds of thirteen key repositories under the RT-Thread org, GitHub repository search (rt-thread keyword and topic:rt-thread), six Google News queries in Chinese and English (via proxy), HN Algolia, EET China RT-Thread official column, World Internet Conference official website and Cyberspace Administration press releases, Phoenix News business news, club.rt-thread.org forum (still restricted by the site’s WAF this issue)

Issue Index

  • I. Kernel and Version Updates
    • Hardening of getaddrinfo’s nested user pointers merged: a single snapshot replaces layered validation (11-03)
    • DM365 SPI prescaler divide-by-zero: passing max_hz as 0 triggers it (11-03)
    • mailbox test case fails on the second run: four completion flags are never cleared (11-03)
    • Macro comments at end of line or above: coding standard adds a section of criteria (11-03)
  • II. Security Follow-up and Pending Merge Queue
    • timerfd accepts any fd: two system calls lead to kernel PC control (11-04)
    • POSIX timer id is not validated: on RT-Smart it can overwrite the console device (11-03)
    • Arbitrary kernel write via block device partition ioctl gets a proposal (11-03)
    • Queue: pipe patch still being revised, five old items remain open (11-03)
  • III. Official and Community Events
    • Wuzhen “Xinguang”: AIOS foundation selected, presentation on virtualized hybrid deployment (11-02 ~ 11-03)
    • Open Source AIOS Alliance discusses small embodied intelligence, RT-Thread presents three types of Agent solutions (11-03)
    • Official news API still stuck at June, release channel remains the media column (11-04)
  • IV. Ecosystem and Vendor Adaptation
    • Fire (Yehuo) HPM6750 BTB Studio BSP published to GitHub, installation process written as five steps (11-04)
    • Nuvoton N9H30 community BSP: the ARM926EJ-S veteran of HMI platforms (11-03)
    • Dual-MCU disinfection device: M7 handles motion, M3 handles spraying, both run RT-Thread (11-03)
  • V. Industry Applications
    • RV32IM dual-issue FPGA CPU integrates RT-Thread Nano into its CoreMark verification chain (11-03)
  • VI. Trends and Summary for This Issue
    • Trend: security side moves from reports to proposals, testing side moves from checklists to code
    • Limitations and deduplication notes

I. Kernel and Version Dynamics

1.1 Nested user-pointer hardening for getaddrinfo merged: a single snapshot replaces layered validation (11-03)

Date: 2026-11-03 09:04 (merge time)　Source: PR #11977

The maintainer rework reported in the previous issue was merged at the start of this window: 57 lines added, 17 removed, touching only syscall_netdb.c under the network syscall directory.

The flaw in the original implementation was layered validation: only the top-level res buffer passed in by the user was checked, after which the resolved socket address was written through res->ai_addr, a user-controlled nested pointer—under Smart/MMU builds this turned a single getaddrinfo() into an arbitrary kernel write. The hints fields were still read directly from user memory after the top-level check passed, leaving a TOCTOU window in between. The return-value check on the servname copy was also wrong—comparing a size_t against 0, which is always false.

The fix uses lwp_get_from_user() to copy res and hints into a temporary kernel structure in one shot, after which all nested pointers come from this validated snapshot; nested sockaddrs and the outer addrinfo are written back uniformly with lwp_put_to_user(), with the target address range validated by the existing helper, so the kernel no longer dereferences unchecked user pointers. Along the way, the kernel addrinfo is allocated by sizeof(*k_hints), and k_res is freed on the newly added error paths.

The value of this change is not in the line count but in the pattern it demonstrates: for nested user pointers, layered validation has an inherent TOCTOU gap, and a one-shot snapshot is the provably safe path. The author notes in the PR that verification consisted only of compiling syscall_netdb.o under the K230 RT-Smart configuration, with the full build left to CI, and no user-mode privilege-escalation reproduction.

1.2 DM365 SPI prescaler divide-by-zero triggered when max_hz is 0 (11-03)

Date: 2026-11-03 13:11 (merge time)　Source: PR #11957, Issue #11950

6 lines added, touching only bsp/dm365/drivers/spi-davinci.c—the smallest change in this window.

davinci_spi_setup_transfer() passes cfg->max_hz straight to davinci_spi_get_prescale(), which computes DIV_ROUND_UP(clk_get_rate(dspi->clk), max_speed_hz). If max_hz is 0 in the configuration and the data width is valid, this division lands on zero and faults immediately. The fix checks max_hz == 0 before computing the prescaler and returns -RT_EINVAL; the non-zero-rate path is untouched.

The verification conditions are stated honestly: no DM365 hardware was available, so only two things were done—compiling bsp/dm365/drivers/spi-davinci.c with arm-none-eabi-gcc produced no new warnings; and replicating the width check and prescaler logic on the host side, data_width = 9, max_hz = 0 produced SIGFPE before the change and returns -RT_EINVAL after, while the prescaler result at 1 MHz matches the pre-change behavior. DM365 is an old TI ARM9 platform, and BSPs like this have almost no test coverage; adding the divide-by-zero guard is already a net gain.

1.3 mailbox test case always fails on second run: four completion flags never cleared (11-03)

Date: 2026-11-03 10:53 (merge time)　Source: PR #11963, Issue #6565

11 lines added, touching only src/utest/mailbox_tc.c.

The symptom is that running core.ipc_mailbox a second time within the same boot always fails: the first run passes, and the second triggers an assertion failure rt_object_get_type(...) == RT_Object_Class_MailBox in the receiving thread, at _rt_mb_recv() line 2884. The root cause is that the four *_thread_finish flags are only ever set to 1 by the worker threads and never cleared; on the second run the test body’s wait loop while (static_mb_recv_thread_finish != 1 || ...) falls straight through, so rt_mb_detach() is called while the worker thread started in this round is still blocked in rt_mb_recv() and has not yet exited; the thread then resumes with an error and continues using a mailbox that has already been detached. The dynamic-mailbox half has the same shape, just never triggered separately.

The fix clears the flags in utest_tc_init(), a hook the utest framework calls before each test case run. Issue #6565 is an old ticket opened in 2021; this change fixes the remaining half of it.

1.4 Macro comments at end of line or above: coding style gains a section of criteria (11-03)

Date: 2026-11-03 09:48 (merge time)　Source: PR #11973, Issue #10097

72 lines added, all in documentation: 32 lines in coding_style_cn.md and 40 in coding_style_en.md, each adding a “Macro Comments” subsection to Section 8, with no code changes.

The original style guide only said “statement comments may only be placed above or to the right of the code,” without saying which form macros should use or why, so both styles coexist in the same repository. The author surveyed the status quo before setting the rule: under include/, 135 macro comments use trailing /**<, of which 87 (64.4%) exceed 80 columns, with line 24 of kerrno.h at 95 columns—groups of constant macros deliberately keep column alignment and accept the overrun. So the criterion is not line length but “how much explanation is needed”: if one comment suffices, put it at end of line; if a paragraph is needed (parameterized macros, where inputs, expansion results, and usage constraints must be described), put it above with @def.

The documentation also adds a practical difference: with MACRO_EXPANSION enabled, a trailing /**< attaches to the macro’s expansion point, so when the same macro expands in multiple places the comment position may be unexpected; a block comment above always binds to the definition site. Therefore macros that expand frequently should prefer a block comment above. All examples are taken from real code in the repository (the error-code group in kerrno.h, RT_ALIGN in rtdef.h), not invented.

II. Security Follow-up and Merge Queue

2.1 timerfd accepts arbitrary fd: two system calls yield kernel PC control (11-04)

Date: 2026-11-04 01:08 (report time)　Source: Defect #11984

Reported by XueDugu, baseline master 5d1fb66d13 (v5.4.0-dev). The impact statement notes: affected since v5.0.2, introduced by 7c2f807a on 2023-09-23 (the timerfd system call merge, i.e. #8067).

The issue itself is short: timerfd_do_settime() and timerfd_do_gettime() fetch an arbitrary descriptor from the process fd table, then cast df->vnode->data directly to struct rt_timerfd * without verifying that the file is actually a timerfd. Linux has a file->f_op != &timerfd_fops check at the same spot that returns -EINVAL; RT-Thread has no equivalent. So the vnode->data of any user-reachable fd object gets treated as a timerfd: the kernel takes and releases a forged mutex inside a foreign object, writes the attacker-supplied itimerspec into it, then dereferences tfd->timer (a linked-list unlink plus rt_free on an arbitrary qword).

What is truly fatal is a negative it_value.tv_sec: it causes timerfd_timeout(tfd) to run synchronously, and its first statement rt_wqueue_wakeup(&tfd->timerfd_queue, POLLIN) walks the wait-queue head read from the confused object and calls entry->wakeup(entry, key) — an indirect function-pointer call where both the pointer and r0 come from attacker-chosen memory.

The report gives the full chain: on 32-bit RT-Thread, signalfd is the perfect confusion object — the first 128 bytes of its context are sigset_t sigmask, copied verbatim from a user pointer by signalfd() (NUL bytes allowed), enough to cover a forged timerfd header, including setting the rt_mutex type byte to the mutex type, leaving owner at 0 so the take succeeds immediately, and setting timerfd_queue.waiting_list.next. Because the RT-Smart kernel shares page tables with user space and dereferences user mappings directly, the forged wait-queue node can live in the attacker’s own user memory.

The reproduction environment is qemu-vexpress-a9 with a default RT_USING_SMART build (timerfd and signalfd are on by default under Smart), running a libc-free user-mode ELF as /sbin/init. The control group calling into a real timerfd returns 0 and the kernel survives; the attack group does signalfd(-1, mask, 0) plus timerfd_settime(sfd, 0, {it_value.tv_sec = -1}), producing a kernel prefetch abort with fully controlled PC, byte-for-byte identical across three runs, with r00:0x10000 visible in the registers. The conclusion: two unprivileged system calls, both official POSIX-style interfaces, are enough to achieve kernel control-flow hijacking.

2.2 POSIX timer id is unvalidated; console device can be overwritten on RT-Smart (11-03)

Date: 2026-11-03 12:35 (report time)　Source: Defect #11980

Same reporter, earlier the same day. timer_gettime() and timer_settime() use the user-supplied timer_t directly as an index: timer = _g_timerid[(rt_ubase_t)timerid], with no timerid < TIMER_ID_MAX check. The sibling function timer_delete() has that check, so this is not a design trade-off but an omission.

On an ordinary MCU build this is an out-of-bounds read; on RT-Smart it goes further — an attacker can pick a pointer that happens to sit next to _g_timerid and reinterpret the target kernel object as a struct timer_obj. The specific alias found in the QEMU image is index 0x35a5 (13733) pointing at _console_device: timer_settime() then overwrites fields of this live UART device with the attacker-controlled itimerspec, including rx_indicate and ops, so a single received UART byte jumps control flow to an attacker-specified address, running at EL1.

Hardware-side verification was also done: on a Pico 2 W (RP2350) built with the original ctime.c and resource_id.c, disassembly confirms the timer_settime() entry is ldr.w r6, [r5, r0, lsl #2]; running timer_oob with 0x20000000 computes the address as 0xa000202c, which is unmapped, and after the fault the USB CDC connection disappears or the shell stalls. The software baseline is likewise v5.4.0-dev, the introducing commit is 077e9841, and the first affected version is v5.0.2.

2.3 Arbitrary kernel write in block-device partition ioctl gets a proposal (11-03)

Date: 2026-11-03 15:51 (proposal time)　Source: Proposal #11981, Defect #11952

19 lines added, 5 removed, one file changed, author liangzhan5, proposal self-marked as draft.

The problem is in RT_DEVICE_CTRL_BLK_PARTITION: the command treats a raw pointer passed from user space as the destination of rt_memcpy, letting an unprivileged process achieve arbitrary kernel writes. There is a secondary flaw — err is not updated after rt_memcpy completes, so even when the ioctl ultimately returns -1, the target address has already been modified, and the error code does not match reality. The author also notes that commands such as RT_DEVICE_CTRL_BLK_GETGEOME may have the same class of problem.

The fix takes two paths: under RT_USING_LWP, use lwp_self() to determine whether the current context is user mode; if so, first copy the partition data to a temporary kernel-stack variable, then safely copy it back with lwp_put_to_user(), returning -EFAULT and performing no write when the pointer is invalid; for non-user (in-kernel) calls, keep the original rt_memcpy path and add err = RT_EOK. Verification only extends to compiling on qemu-vexpress-a9 and manual review.

The corresponding defect #11952 was opened on October 29 by the same reporter — 5 days from report to proposal.

2.4 Queue: pipe patch still in revision, five older items remain open (11-03)

Date: 2026-11-03 (proposal update time)　Source: Proposal #11971, Proposal #11954, Proposal #11911, Proposal #11918, Proposal #11947, Proposal #11935

The pipe FIONREAD patch reported last issue (#11971) was updated again on 11-03 16:13 and is still unmerged. The approach is unchanged: first compute the ring-buffer data length or free space into an int on the stack, copy it back to the user address with lwp_put_to_user() in MMU builds, keep the direct write in non-MMU builds; also add null checks for pipe and pipe->fifo, and wrap the lwp_user_mm.h include in ARCH_MM_MMU.

Status of the other five in the queue: cromfs directory-name bounds (#11911), poll/epoll count multiplication wraparound (#11954), 9pfs client trusting server-supplied length (#11918), unbounded search after DHCP address-pool exhaustion (#11947), and signalfd listener removal on close (#11935) — none merged this issue. Yesterday’s merge #11978 (GPT partition first/last LBA swapped) is now closed.

III. Official and Community Activities

3.1 Wuzhen “New Light”: AIOS Foundation Selected, the Story Is Virtualized Hybrid Deployment (11-02 ~ 11-03)

Date: 2026-11-02 (expo opening) / 2026-11-03 14:30 (official column publication)　Source: EE Times China: RT-Thread Appears at Wuzhen Summit, World Internet Conference: Expo Opens in Wuzhen, CAC press release

The 2026 World Internet Conference Wuzhen Summit runs November 2–5 in Wuzhen, Zhejiang, with the “Light of the Internet” Expo opening on the morning of November 2. Official figures: 671 Chinese and foreign companies and institutions from 54 countries and regions exhibiting, more than 1,000 new technologies and products showcased and released, and 35 “New Light” products and 20 “New Shine” scenarios selected and promoted.

The position RT-Thread (Ruiside) secured at this summit is a spot on the “New Light” product promotion list—the selected entry being the company’s independently developed “RT-Thread Heterogeneous Converged Edge-Side Intelligent AIOS Foundation.” Ecosystem Director Li Yan delivered a keynote on site at the expo titled “Virtualized Hybrid Deployment Embodied Intelligence Solution · AI Kit.”

The foundation’s technical proposition is stated clearly: the hybrid deployment architecture places AI inference on the Linux side and real-time control on the RT-Thread side, with the two sides running independently without interfering with each other—even if the AI side fails, the control side can still execute stably, with official claims of microsecond-level control precision. The accompanying AI Kit bundles the inference engine, model optimization, hardware adaptation, and debugging environment into a single toolchain, pitched at letting developers avoid having to “master a particular chip or a particular framework” and instead cover the entire workflow with one set of tools.

What’s worth noting here is the shift in narrative framing. In the past, RT-Thread presented itself as a “real-time control foundation” and “the domestic embedded operating system with the largest installed base”; this time the selected vehicle is an edge-side intelligent operating system, positioned around coordination between a robot’s “brain” and “cerebellum.” The line in the official release—”a key leap from a real-time control foundation to an edge-side intelligent operating system”—is the formal version of this narrative. On numbers, the release cites a community of roughly 300,000 developers, consistent with previous figures.

3.2 Open Source AIOS Alliance Discusses Small Embodied Intelligence, RT-Thread Presents Three Agent Solutions (11-03)

Date: 2026-11-03 17:14 (report time) / 2026-10-23 (event date)　Source: Phoenix Net: Open Source AIOS Alliance Assembles at WTCC 2026

A commercial press release published only on 11-03 covers the “Jishu Maker Workshop: Small Embodied Intelligence Solution Seminar” held during the Shanghai West Bund International Tech Consumer Carnival (WTCC 2026) on October 23. The organizer was Arm China’s Jishu community, sharing the stage with three partners from the “Open Source AIOS Alliance”: Rockchip, Radxa Computer, and RT-Thread.

Arm China launched this alliance in July of this year, focusing on capabilities such as continuous perception, autonomous execution, and long-term memory, and simultaneously rolled out two deliverables, JishuFriends and JishuBuddy: the former’s first prototype, Puppy, uses a robot dog as its vehicle, integrating environmental perception, voice and vision interaction, and autonomous mobility; the latter is a hardware development tool for Agentic AI, taking natural language as its entry point, targeting Arm-architecture embedded devices, and able to link simulated environments with real embodied devices.

RT-Thread was represented by senior AI engineer Zheng Wei, who presented three Agent solutions—robot dog, HyperCar, and Codex orchestration—with the thrust of pushing agents from “conversation” to “execution,” and stating explicitly that RT-Thread will focus on embodied intelligence projects and work with Arm China to connect Agent capabilities to real applications. The division of labor among the three partners is also fairly clear in this release: Rockchip discussed decoupling compute and control via host SoC plus AI co-processor, Radxa discussed using open-source hardware like ZERO 3W for prototype-to-volume delivery, and RT-Thread discussed system-side Agent scheduling and execution.

One timing caveat: the event took place on October 23, and the report only appeared on November 3. It is included in this issue because it is the first time RT-Thread’s specific technical role within the alliance has been laid out—not because it is an event that occurred that day.

3.3 Official News Endpoint Still Stuck at June, Publishing Outlet Remains Media Columns (11-04)

Date: 2026-11-04 (verification)　Source: RT-Thread official news list

The latest entry returned by the official news endpoint getList?type=rt_org is still the 2026-06-17 item “Ruiside Technology Invited to Attend the 2026 Abu Dhabi Investment Forum,” and the news section on the official homepage is likewise stuck at June, with nothing new this issue. The official site’s news module itself fails to load (the page reports “Oops, loading failed”), so the list page can only be verified via the endpoint.

The actual publishing outlet is media columns: this issue, RT-Thread’s official column on EE Times China updated with one piece (the 11-03 Wuzhen “New Light” article); the earlier 11-01 Double 11 promotion article is promotional content and was not included. The forum club.rt-thread.org still returns 468 behind a WAF challenge page, so thread lists and post bodies cannot be read directly; the community discussion side can only be cross-verified via GitHub and media columns.

IV. Ecosystem and Vendor Adaptation

4.1 Fire HPM6750 BTB’s Studio BSP Goes Up on GitHub, Installation Process Written as Five Steps (11-04)

Date: 2026-11-04 03:47 (repository creation)　Source: Repository: rt-thread-bsp-hpm6750-fire-btb

A personally maintained RT-Thread Studio board support package, targeting the Fire HPM6750 BTB development board. The README’s parameter table is quite complete: BSP version 1.0.19, MCU is HPM6750IVM2 (dual-core 32-bit RISC-V, up to 816 MHz), RT-Thread Full / Latest (tested running on 5.4.0), toolchain RISC-V GCC 11.1.0, console via UART0 on PY06/PY07 (115200 8N1), debugging via external JTAG (noting this board does not support SWD).

The installation process is written as five steps: download the BSP ZIP from Releases, install the resource package in Studio’s SDK Manager, select HPM6750-FIRE-BTB when creating a new project, check peripherals in RT-Thread Settings, and after compiling, download via USB, DAPLink, or J-Link. This approach follows the same pattern as the batch of official HPMicro BSP repositories, except the maintainer has shifted from the chip vendor to an individual.

What’s worth noting is the frequency of such repositories appearing. Yesterday we reported that HPMicro pushed 12 official BSPs to v1.13.0 within thirteen minutes; today we see a third-party board also being filled in following the same engineering structure—BSPs split into independent repositories, maintained as Studio projects. This convention has spilled over from the vendor to the community and become a de facto standard.

4.2 Nuvoton N9H30 Community BSP: The ARM926EJ-S Veteran of HMI Platforms (11-03)

Date: 2026-11-03 20:13 (push time)　Source: Repository: sdk-bsp-nk-n9h30

A community BSP for the Nuvoton N9H series, targeting the N9H30F61IEC or N9H30F63IEC chip. This part has an ARM926EJ-S core at up to 300 MHz, a built-in TFT LCD controller and 2D graphics acceleration, a parallel interface capable of driving up to 1024x768 at 24-bit color, 64 MB of on-chip DDR, and comes in an LQFP216 MCP package.

The N9H is a typical human-machine interface platform: modest compute, complete display and peripheral interfaces, and a cheap BOM—suitable for industrial HMI, access control, and appliance panels. RT-Thread’s BSPs on such MPUs have always been community-maintained, and Nuvoton’s official support is far less dense than its MCU line, so every repository that runs successfully has reference value for selection.

4.3 Dual-MCU Disinfection Device: M7 Handles Motion, M3 Handles Spraying, Both Run RT-Thread (11-03)

Date: 2026-11-03 14:02 (push time)　Source: Repository: GD32

A competition project called “Jingxun Weishi” (Clean Patrol Guardian), an intelligent disinfection mobile device for small and medium public areas such as classrooms, corridors, and public seating. The architecture is dual-MCU: GD32H759IMT6 (Cortex-M7) as the motion main controller, STM32F103C8T6 (Cortex-M3) for spray control, both running RT-Thread 4.1.1.

Functionality covers four-wheel differential movement, robotic arm atomizing spray, HX711 weighing for remaining-volume monitoring, remote control, scheduled disinfection, status reporting, and video feedback. The repository structure is more organized than most competition projects: docs/ contains hardware descriptions, communication protocols, code style, and submission documents; scripts/ contains Keil build and repository self-check scripts; and a clang-format configuration is included.

The point of such projects isn’t technical difficulty but the engineering trade-off of “one M7 isn’t enough, add an M3 to share the load”: motion control demands real-time performance, while spraying and remaining-volume monitoring are slow variables. Splitting them leaves headroom on both chips, and the communication cost is covered by a single serial protocol.

V. Industry Applications

5.1 RV32IM Dual-Issue FPGA CPU Brings RT-Thread Nano into the CoreMark Verification Chain (11-03)

Date: 2026-11-03 20:58 (push time)　Source: Repository: RISC-V-CPU

An RV32IM pipelined CPU project targeting Xilinx Kintex-7, with the latest push updating the experiment entry point. On the CPU side: RV32IM instruction set, machine-mode CSRs and timer interrupts, a main execution channel plus an integer side channel supporting eligible dual-instruction pairing; the front end has BTB, RAS, and indirect jump prediction, while the memory side has dual-channel forwarding, load/store pairing, and cache-hit bypass.

The software side is where RT-Thread comes in: it runs RT-Thread Nano v3.1.5, with a UART command line and CoreMark 1.0, plus an optional cmcrc16 custom instruction. Target device is xc7k325tffg900-2, Vivado 2023.2.

The verification data is more detailed than typical hobby projects: with timingopt15 plus a 256-line DCache and an ideal 180 MHz clock, a 100-iteration CoreMark behavioral simulation yields 31,445,017 CPU cycles, 30,605,777 retired instructions, CPI 1.027421, a final CRC of 0x988c, and 7 directed regressions passing. Shortcomings are also stated: after routing at 180 MHz, WNS is -1.371 ns and WHS is +0.013 ns—timing has not converged and no bitstream has been generated; the 100-iteration simulation is only for functional and CPI comparison, and on-board frequency is subject to the implementation report.

For RT-Thread, the significance here is that Nano has once again been used as the minimal runnable software stack for CPU verification—exposing problems in interrupt, context-switch, and timer paths better than bare-metal tests.

In the 24 hours of this issue, 4 pull requests were merged into the main repository (#11977, #11973, #11963, #11957), 4 new proposals were opened (#11979, #11981, #11982, #11983), and 2 new defects were filed (#11980, #11984). The volume is on par with the previous issue, but the structure has changed: the previous issue was about clearing the backlog, while this issue is about opening new accounts and shoring up infrastructure.

The first thread is the two new security reports, which are highly consistent in shape—both are “descriptors or identifiers not type-checked.” timerfd does not check whether the fd is a timerfd, and the POSIX timer does not check whether the id is out of bounds; both entry points treat the user-supplied value directly as an entry pointing to a kernel object. Together with the previous issue’s graphics negative offset (user-supplied offset not sign-checked) and pipe (user pointer not validated), the four can be grouped into the same class: RT-Smart’s syscall layer lacks unified validation at the “value → object” step. The fixes for this class of defect are not complicated; the hard part is finding all the entry points.

The second thread is that response speed is increasing. #11952 was a block device partition arbitrary write reported on October 29, and by November 3 there was proposal #11981; yesterday’s getaddrinfo rework (#11977) was merged today; the pipe patch continues to be updated in the queue. The four stages—report, proposal, maintainer rework, and merge—can now be completed within a few days, a clear change from the previous issue’s assessment of “many reports, few patches.” The cost is that review pressure has shifted to the maintainers’ side—five items remain under review in the queue, and each requires someone to read and understand the reproduction steps.

The third thread is that the Z-version test checklist has begun producing code. #11972, reported in the previous issue, broke down “can the Z version ship” into per-framework QEMU and utest checklists, and this issue saw three proposals directly referencing it: an in-firmware virtual loopback bus for SPI (#11979), a simulated bus utest for the I2C framework (#11982), and #11983, which adds looping and memory sampling to automated runs (this one is a follow-up to #11963, solving the problem that “running only once cannot detect memory leaks”). Combined with today’s merged mailbox test case that can be run repeatedly, the testing foundation on the CI side is moving toward “repeatable and observable.”

On the ecosystem side, two moves in opposite directions are both worth watching: on one hand, a chip vendor is scripting batch releases of BSP repositories (HPMicro’s 12 repositories at the same version yesterday); on the other hand, individual developers are adding Studio BSPs for third-party boards such as the Wildfire HPM6750 BTB and community BSPs for older platforms such as the Nuvoton N9H30. Vendors ensure consistency across boards, while the community fills in long-tail coverage—together these two ends form the full picture of RT-Thread’s board-level ecosystem.

On the events side, Wuzhen “Xinguang” is the most significant item in this issue: a national-level platform included the “heterogeneous converged edge intelligent AIOS foundation” among 35 promoted products, shifting the narrative from “real-time control foundation” to “edge intelligent operating system,” with the focus on robot “brain” and “cerebellum” coordination. The WTCC alliance article that appeared the same day is exactly this narrative in a specific scenario—three types of Agent solutions, the division of labor with Arm China, and an emphasis on embodied intelligence. Promotion and engineering are on the same line, which is rare in past event articles.

6.2 Limitations and Deduplication Notes

The forum club.rt-thread.org still returned 468 with a WAF challenge page in front of it during this issue, so the post list and body text could not be read; the information gap on the community discussion side was filled by GitHub and media columns. Both the official news API and the official website news list are stuck at June 17, and the official website news module itself fails to load.

The GitHub anonymous API rate limit (60 requests per hour) was exhausted in the later part of collection, so the organization-level full push check was switched to Atom commit checks across thirteen key repositories (packages, env, rtthread-nano, sdk, smart-build, UtestRunner, userapps, etc.); none had commits within the window, and only the main repository had pushes. For defect #11950, only the title and summary were obtained, and the body was not read; the PoC details of #11984 and #11980 are all quoted from the report body and were not independently reproduced—the report already states them with the original qualifying conditions (QEMU model, baseline commit, affected versions).

On the Chinese side of Google News, there were 5 hits within three days, of which 2 were included (Wuzhen “Xinguang” and the WTCC alliance article); the Double Eleven promotional article is promotional and outside the window, so it was not included, and the Shanghai Open Source Competition article was already reported in the previous issue. On the English side, two sets of queries returned zero hits. All 5 HN Algolia hits within the window were about the Thread networking protocol, hiring boards, and Mbed TLS maintenance, unrelated to this topic, and were excluded.

Deduplication: the #11977 proposal reported yesterday was merged in this issue, handled as “progress” and recorded as an item; #11971, #11954, #11911, #11918, #11947, and #11935 were already listed in the previous issue, so only status changes are recorded here and they are not repeated as items; #11978 was closed yesterday and is not expanded upon in this issue.

Appendix: Source Verification Table and Source List

Source Verification Table

Source Verification Result
Official news API (rt_org) No new items in 24 hours; latest entry remains at 2026-06-17
Official website news list Homepage news section still shows June; news module failed to load
Community forum Fronted by a WAF challenge page (HTTP 468); list and body content unreadable
Main repo commits 4 within the window, clustered between 11-03 09:04 and 13:11
Main repo PRs 4 merged (#11977, #11973, #11963, #11957); 4 newly opened (#11979, #11981, #11982, #11983)
Main repo Issues 2 newly opened (#11980, #11984), both RT-Smart security issues
Main repo releases and tags No new items; latest remains v5.3.0 (2026-09-10)
Key RT-Thread org repos Atom checks on thirteen repos; no commits within the window
GitHub repo search 2 new RT-Thread-related repos (HPM6750 BTB BSP, N9H30 BSP); 3 topic hits
Google News Chinese 5 items within 3 days; 2 included (Wuzhen New Light, WTCC alliance piece)
Google News English Zero hits
HN Algolia 5 items, all Thread protocol or hiring content, off-topic
EET-China official column One Wuzhen piece on 11-03, included
World Internet Conference official site / CAC Expo opening and the 35 “New Light” items, used to cross-check the official release

Full Source List