Research window: 2026-10-26 08:00 ~ 2026-10-27 08:00 (Beijing Time, 24 hours)

Sources: RT-Thread official news API and community article API, GitHub (main repository commits / PR / Issue / releases / tags, RT-Thread/sdk, vscode-rt-smart, packages, pkgs-test, topic:rt-thread ecosystem search), Google News aggregation (six queries in Chinese and English, via proxy), HN Algolia, industry media (Electronic Engineering Album RT-Thread column) and vendor channel verification (see appendix source list for details)

Issue Index

  • I. Kernel and Version Dynamics
    • Mainline has zero commits in 24 hours, last commit still lwIP loopback; within the organization only the VS Code extension is active (10-26)
    • Pending merge queue: 13 proposals updated on the same day, only one new addition: Renesas RA6W1 (10-26)
  • II. Security and Stability Follow-up
    • signalfd global counter out-of-bounds: from the 11th call onward, kernel pointers are written outside the heap block (10-26)
    • musl thread list use-after-free under concurrent exit: futex lock fails to provide mutual exclusion (10-26)
    • Two time subsystem fixes promoted to mature release: settimeofday cast removal, gmtime_r handling of negative timestamps (10-26)
    • ESP-IDF v6.1 include order fixed on the package side: main repo proposal closed, esp-idf package proposal merged (10-26)
  • III. Toolchain and Developer Experience
    • vscode-rt-smart 0.4.14 merged: 4826 lines removed, extension scaled back from IDE to Env entry point (10-26)
    • Eclipse project generator misses kernel macros: solution found for Studio’s 24 implicit declaration warnings (10-26)
  • IV. Ecosystem and Vendor Adaptation
    • Renesas RA6W1 submits system resource allocation optimization, BSP enters phase-two refinement (10-26)
    • STM32 Ethernet adds ops layer and SR8201F PHY, ADC log level lowered (10-26)
  • V. Official and Community
    • Official news API has no new items in 24 hours, latest issue remains June 17 (10-26)
    • Community long-form article “rtthread Startup Chain Analysis”: Reset_Handler to main split into three stages (10-26)
    • No new media articles in 24 hours, most recent still the 10-24 RISC-V Summit report (10-26)
  • VI. Summary and Trend Observations
    • This issue’s trend: merges stalled, defect reports and toolchain rework take over
    • Limitations and deduplication notes

I. Kernel and Version Dynamics

1.1 Mainline sees zero commits in 24 hours; last commit is still the lwIP loopback, and only the VS Code extension is moving within the org (10-26)

Date: 2026-10-26 (verification time)　Source: main repo commit log, org repository list

No commits landed on master in this window. The last commit in the main repo is still the 10-25 19:26 lwIP loopback netdev (#11893), preceded by the 10-23 clang-format rule cleanup (#11859); both were covered in the previous report. In other words, mainline code made no progress throughout 10-26 — no new merges and no maintenance commits pushed directly to master.

The org level is equally quiet: of 35 repositories, only 6 have seen pushes in the past 7 days, and only one falls within the 24-hour window — vscode-rt-smart (a merge commit at 10-26 22:35). The most recent activity in sdk and toolchains-ci stopped at 10-26 07:57 and 00:33 respectively, both before the start of the window, covering the TriCore toolchain and QEMU emulator packages written about in the previous report. The last commits in packages and pkgs-test remain 10-23.

Nothing has changed on the version side: the latest release and tag are still v5.3.0 from 09-10, with no pre-releases and no new tags.

1.2 13 proposals in the pending queue updated on the same day, with only one new addition, Renesas RA6W1 (10-26)

Date: 2026-10-26 (last updated)　Source: main repo pull request list

A total of 13 proposals saw new activity within 24 hours: 12 remain under review, 1 was closed, and none were merged — the most recent merge is still #11893 from 10-25. The breakdown is fairly concentrated: 6 fixes (tmpfs truncation #11910, dlmodule uninitialized globals #11915, serial rx_indicate #11931, settimeofday #11928, gmtime_r #11929, NVMe namespace leak #11920), 3 BSP and driver items (ESP32-S3 #11844, RA6W1 #11934, STM32 Ethernet #11819), and 3 tooling items (Eclipse export #11930, mkdist #11874, Keil/IAR target selection #11743). The closed one is #11926 (see 2.4).

Only one new proposal was opened that day: #11934. Fixes account for more than half, indicating that review activity is still ongoing, just without resulting in merges. The search results also include two old proposals from 2018 and 2019 (#1956, #2461) that appeared in the updated list due to index refresh; they are not counted in the statistics.

II. Security and Stability Follow-up

2.1 signalfd global counter out-of-bounds: from the 11th call onward, kernel pointers are written outside the heap block (10-26)

Date: 2026-10-26 16:13 (creation time)　Source: Issue #11933

This is the most significant item in this issue. The researcher points out that
components/libc/posix/io/signalfd/signalfd.c uses a file-scope global counter is_head_init to index the per-file-descriptor private array sfd->lwp[10], and signalfd_add_notify() performs no bounds check before use. signalfd_close() never rolls back this counter, so it only increases and never decreases; when a new context is created, only lwp[0 .. is_head_init-1] is cleared, so a second creation in the same process can never match its own entry and inevitably takes the write branch.

The consequences are described concretely: lwp[] is the last member of struct rt_signalfd_ctx, and the entire structure is 1536 bytes on arm32, so the array sits exactly at the end of the heap block. On the 11th call to signalfd(-1, ...), the write lands on the first word outside the allocated block, i.e., the next block header of the small memory allocator; thereafter each creation pushes it 4 bytes further out (8-byte stride on 64-bit), forming a continuous kernel heap out-of-bounds write whose pace is controlled by the caller, and the value written is a kernel pointer.

The impact scope was checked tag by tag by the author: the introducing commit is 7c3d966d (#8001) from 2023-09-11, and v5.0.2 / v5.1.0 / v5.2.0 / v5.2.1 / v5.2.2 / v5.3.0 as well as current master (5d1fb66d) are all affected. The only trigger precondition is RT_USING_SMART=y—RT_USING_POSIX_SIGNALFD defaults to y under that configuration, and both official QEMU Smart BSP configurations also enable it, so a default RT-Smart build can trigger it. Reproduction uses bsp/qemu-vexpress-a9 (Cortex-A9, 32-bit, FAT sd card root filesystem), with the PoC installed as /sbin/init.

Currently there is no corresponding fix proposal for this issue, and it has not been labeled.

2.2 musl thread list use-after-free under concurrent exit: the futex lock fails to provide mutual exclusion (10-26)

Date: 2026-10-26 11:22 (creation time)　Source: Issue #11932

The second defect report comes from another reporter, in an environment of RT-Thread 5.2.2 RT-Smart, SMP, aarch64, musl 1.2.5. The symptom is a user process crash during concurrent pthread_create and pthread_exit, with the crash point in musl_pthread_exit: the thread descriptor written during list removal has already been freed or unmapped (Data Abort), or the thread’s return address has been overwritten with 0 (Instruction Abort).

The author’s conclusion is that the problem is entirely in user space: musl uses the futex-based __tl_lock / __tl_sync to protect the thread list, but under SMP concurrent exit this set of locks does not truly provide mutual exclusion, causing the doubly linked list to be corrupted; the kernel-side futex implementation itself is semantically correct and is not responsible for this defect. The reproduction material is a 1000-round, 8-thread tl_race program, which crashes within a few hundred rounds.

This issue carries three labels: bug, Arch: ARM/AArch64, and RT-Smart, and includes a complete analysis document. Like 2.1, it falls on the RT-Smart line, but at a different layer: 2.1 is the kernel heap, while this one is user-space libc.

2.3 Two time subsystem fixes move to mature status: settimeofday cast removal, gmtime_r handling of negative timestamps (10-26)

Date: 2026-10-26 14:17 and 17:48 (last updated)　Source: PR #11928, PR #11929

The two corresponding fixes for the four time subsystem issues recorded in the previous issue advanced one step within this window, and both checked “mature version, can be merged”.

#11928 changes only one file, +185/-135: settimeofday() originally cast tv_sec with (long) before checking its sign; under a configuration where ILP32 has a 64-bit time_t and a 32-bit long, valid timestamps between 2^31 and 2^32-1 are truncated into negative numbers, and the function rejects them with EINVAL before touching the RTC device—2208988800 (2040-01-01) is rejected this way. The fix validates by the field’s own type without casting.

#11929 changes two files, +104/-9: gmtime_r() splits the timestamp using C division and modulo, but C division truncates toward zero, so under negative input the remainder is negative, and the year loop can only move toward the future; thus -1 yields 1970-01-01 00:00:-1, and -31536000 turns the year field into 1970-01--364. The fix normalizes the negative path before splitting.

Neither has been merged. The other two (the timer_gettime() truncation #11924 and the time subsystem work item investigation #11927) saw no new progress in this window.

2.4 ESP-IDF v6.1 include order now fixed on the package side: main repo proposal closed, esp-idf package proposal merged (10-26)

Date: 2026-10-26 09:15 and 11:37 (merge and close times)　Source: RT-Thread-packages/esp-idf proposal #19, main repo proposal #11926

#11926, recorded in the previous issue, sought to adjust the FreeRTOS header include order for ESP32 C3/C6 in the main repo to fix the build failure on master after the ESP-IDF v6.1 adaptation. This round of discussion produced another path: a maintainer suggested in a comment “have the AI change idf to scons” and pointed to proposal #19 in the package repo; another maintainer then asked whether the package repo change should be merged first.

The result is that package repo proposal #19 (fix(scons): prioritize RT-Thread FreeRTOS headers) was merged on 10-26 09:15, and main repo #11926 was closed without merging at 11:37. In other words, the header priority issue is resolved at the SCons build script level, and the main repo no longer changes the include order. The significance for BSP maintainers is that esp-idf-related build issues should henceforth be handled in the package repo first, with the main repo only carrying kernel and framework-side changes.

III. Toolchain and Developer Experience

3.1 vscode-rt-smart 0.4.14 merged: 4,826 lines removed, extension scaled back from IDE to Env entry point (10-26)

Date: 2026-10-26 22:35 (merge time)　Source: vscode-rt-smart proposal #38

The only code action in the organization that day was an extension slimming submitted and merged by the maintainer himself. 49 files, +883/-4826, version bumped to 0.4.14, with the resulting vsix at 1,296,751 bytes.

Far more was removed than added: four feature blocks—the Kconfig view, SDK manager, toolchain settings, and Symbolic Analysis—were removed wholesale, along with the ELF and DWARF parsers (elf-parser.ts, dwarf-parser.ts, handleElf.ts, roughly 887 lines combined) and 291 lines of settings documentation. The RT-Thread Setting view was narrowed to only Env installation, updates, and status display, while retaining project root directory configuration.

New additions are an editor built-in browser command and code --open-url URI handling, with the existing authentication callback preserved; 140 lines of browser tests were added alongside, and the author’s stated verification criteria are the four steps npm run compile, npm run lint, npm test (13 passing), and npm run package:vs.

From a product positioning standpoint, this is a clear retreat: the extension no longer attempts to replicate RT-Thread Studio’s configuration and debugging capabilities inside VS Code, keeping only two things—the “Env entry point + embedded browser”—to reduce size and maintenance surface.

3.2 Eclipse project generator misses kernel macros: a fix for Studio’s 24 implicit declaration warnings (10-26)

Date: 2026-10-26 23:33 (last updated)　Source: main repo proposal #11930

The community long-form article covered in the previous issue documented “Studio builds reporting 24 rt_sched_* implicit declaration warnings,” and this round brings a corresponding proposal: single file, +151/-2, fixed from the project generator side.

The root cause is stated clearly: the scheduler interfaces in include/rtsched.h are guarded by the two macros __RT_KERNEL_SOURCE__ and __RT_IPC_SOURCE__, which the gcc and armclang branches inject via LOCAL_CPPDEFINES in src/SConscript. Command-line scons builds recognize them, but tools/targets/eclipse.py, which Studio invokes before every make, does not collect this group-level definition, so dist-exported projects produce 24 -Wimplicit-function-declaration warnings: 1 in clock.c, 7 in ipc.c, 12 in thread.c, 1 in timer.c, and 3 in scheduler_comm.c.

The fix promotes __RT_KERNEL_SOURCE__ to the Kernel group’s global CPPDEFINES, consistent with the existing msvc branch. The change does not touch kernel source code, only the project generation script.

IV. Ecosystem and Vendor Adaptation

4.1 Renesas RA6W1 submits system resource allocation optimization, BSP enters phase two refinement (10-26)

Date: 2026-10-26 18:22 (creation time)　Source: main repo proposal #11934

The only newly opened proposal in this window, from a regular contributor on the Renesas RA6W1 side, branch name rcitach/sboot, 5 files, +191/-110, titled “optimize system resource allocation.”

The RA6W1 BSP follows a two-phase model of “merge the skeleton first, fill in drivers later”: the initial version was merged in August, after which the chip vendor side has been supplementing peripherals and power management in batches. This one lands in phase two, touching startup and resource allocation-related configuration without changing the peripheral driver framework. The verification BSP and .config fields in the proposal template are not yet filled in, and the status remains draft-level.

4.2 STM32 Ethernet adds ops layer and SR8201F PHY, ADC log level lowered (10-26)

Date: 2026-10-26 10:25 (last updated)　Source: main repo proposal #11819

A three-in-one driver proposal, 4 files, +34/-3, covering three independent issues on the STM32 side.

First, the ADC driver’s default log level was too high, flooding output during normal use; it is changed to DBG_WARNING with the macro switch retained. Second, the ETH driver lacked ops layer adaptation, so the upper-layer network framework could not operate the device through a unified interface; this proposal implements and registers the ops callback set. Third, the PHY driver did not support the SR8201F, so boards using that chip could not bring up Ethernet; this proposal adds the identification ID, initialization flow, and register configuration, and adds it to the PHY list. The verification board is stm32f429-atk-apollo, with RT_USING_DEVICE_OPS, BSP_USING_ETH, and PHY_USING_SR8201F enabled in the configuration.

V. Official and Community

5.1 Official news API returns no new items in 24 hours; latest entry remains June 17 (10-26)

Date: 2026-10-26 (verification time)　Source: Official news API

The organization-category news list still returns 5 items, with updatetime values of 2026-06-17 (two items), 06-11, 06-09, and 06-02, covering the Abu Dhabi Investment Forum, the 4th Software Innovation and Development Conference, the Lingang “Dishui Zhihui” embodied intelligence event, the off-campus base designation at Zhangjiang Hi-Tech Experimental Primary School, and the 5th Industrial Technology Forum. All five are past items; no updates in this window.

The API response fields contain no publication date, only updatetime, and the event dates in the body text are earlier than updatetime (for example, the Abu Dhabi forum body text says June 11, and the industrial technology forum says May 27). When citing, use the event date in the body text.

5.2 Community long-form article “rtthread Startup Chain Analysis”: splits Reset_Handler to main into three stages (10-26)

Date: 2026-10-26 08:59 (published)　Source: Community article: rtthread Startup Chain Analysis

The community article API added only this one piece in the window, about 5,700 characters. The author states the environment is STM32F103C8T6 + RT-Thread 4.0.3 + RT-Thread Studio 2.3.1 (GCC), and declares that the code in the article comes from the actual build of this project, not copied from a manual.

The chain is split into three stages: the first is assembly, where Reset_Handler copies .data initial values from Flash to SRAM, zeroes .bss, calls SystemInit, and jumps to entry—the author specifically calls out a common misconception: SystemInit does not configure the main frequency to 72MHz; it only resets RCC to the reset state and sets SCB->VTOR to the Flash start address; the second is C initialization, where entry enters rtthread_startup(), and only inside rt_hw_board_init() are the 72MHz clock and heap configured, after which the main, timer, and idle threads are created; the third is scheduler startup, where rt_system_scheduler_start() picks the highest-priority ready thread, running the timer thread first by default, and main() only appears after rt_components_init() inside main_thread_entry().

The end of the article also provides four “easy-to-misremember points” and a section on self-verification methods, serving as a summary of common confusion points when reading kernel code.

5.3 No new media articles in 24 hours; latest remains the 10-24 RISC-V summit report (10-26)

Date: 2026-10-26 (verification time)　Source: Google News aggregation (Chinese)

Six queries in Chinese and English (exact string 3 days, RT-Thread 7 days, Ruiqing 7 days, English exact string 3 days, RTOS 3 days, operating system 3 days) returned only two old articles: the 10-24 Electronics Engineering Album piece “Edge AI Becomes the New RISC-V Battleground: RT-Thread’s Full-Stack Practice Appears at the 6th RISC-V China Summit,” and the 10-21 piece “Ruiqing Platform V1.8.4 Released: Encoder, MIPI, and GPIO Upgraded Across the Board.” The two were already included in the 10-26 and earlier reports respectively; no new items in this window.

All three English-side queries returned zero hits. HN Algolia’s 19 historical hits stop at 2025-05 at the latest, and the four candidates in the window are all literal false matches on “threads” (a Python thread debugging tool, virtual thread profiling, and the Threads social platform MCP), all of which have been excluded.

VI. Summary and Trend Observations

6.1 This issue’s trend: merges stall, defect reports and toolchain rework take over (10-26)

Date: 2026-10-26 (this issue)　Source: Main repository commit history

Four threads summarize today:

First, the main code line has stalled. Zero commits and zero merges in 24 hours; 13 proposals churned in the queue but none landed. The previous issue’s 72-hour window landed only two, and today’s zero commits continue the same rhythm—development is waiting on review, and review is waiting on fixes and refinement.

Second, the security surface continues to be driven by external researchers. 10-24 was four items in the time subsystem; today it is two in RT-Smart: an out-of-bounds global counter in signalfd (arbitrary kernel heap write, affecting all versions since v5.0.2, triggerable under default configuration) and a concurrent use-after-free in the musl thread list. Neither requires special hardware, both are reproducible in QEMU, and both point to the layer of “Smart builds under default configuration.”

Third, the toolchain side is being handled by the maintainers themselves. vscode-rt-smart cut 4,826 lines in one go, pulling the extension back from a “big all-in-one IDE substitute” to an Env entry point plus an in-editor browser; at the same time, a patch was submitted for the Eclipse export missing kernel macros, directly targeting the 24 implicit declaration warnings under Studio.

Fourth, the vendor side remains BSP-focused. Renesas RA6W1 enters phase two resource allocation optimization, ST adds Ethernet ops and SR8201F PHY, and Espressif’s ESP32-S3 BSP proposal is still awaiting review at the 55-file scale; there are no new chip products or architecture-level moves.

6.2 Limitations and deduplication notes

Date: 2026-10-27 (this issue)　Source: Main repository commit history

First, both the official news API and the community article API have been checked; the former has not been updated since June, and there is no new official content in this issue.

Second, this issue does not overlap with the 10-26 issue: the previous issue’s window ended at 10-26 08:00, and this issue starts from that point. Proposals such as #11910, #11915, #11920, and #11901 were already summarized as “pending-merge defects” in the previous issue and are not expanded again here, appearing only in the queue statistics.

Third, four old proposals—#2461, #1956, #2467, and #5096—are not included: their update times in the search results fall within this window, but their close and merge times are 2019, 2018, 2019, and 2021 respectively, making them index refreshes rather than new events.

Fourth, the GitHub anonymous API rate limit was near its cap this round; the organization-level check was completed with a single sort=pushed request rather than pulling all events per repository; main repository commits are based on the first 100 entries returned by the commits API, which is sufficient to cover the 24-hour window.

Appendix: Source Verification Table

Source Verification Result
RT-Thread official news API (organization category) No new items; still returns 5, latest updatetime remains 06-17
Community article API (article) 1 new item in window: rtthread startup chain analysis (10-26 08:59)
GitHub main repo commits 0 in window; last was the lwIP loopback at 10-25 19:26
GitHub main repo PRs 13 updated, 0 merged, 1 opened (#11934), 1 closed (#11926)
GitHub main repo Issues 2 opened: #11933 signalfd out-of-bounds, #11932 musl thread list UAF
GitHub main repo releases / tags No new release; latest remains v5.3.0 from 09-10
GitHub org repo pushes 6 of 35 repos pushed in the last 7 days; only vscode-rt-smart within the 24-hour window
GitHub RT-Thread/sdk No activity in window (most recent 10-26 07:57, two TriCore packages, already covered last issue)
GitHub RT-Thread/packages No activity in window (last commit 10-23)
GitHub RT-Thread-packages/esp-idf 1 merged: #19 header include-order fix
GitHub RT-Thread/pkgs-test No activity in window (last commit 10-23)
GitHub topic:rt-thread 2 repos pushed (AKP05E firmware, AWTK), both ecosystem references, not covered
Google News aggregation (Chinese and English, via proxy) Six query sets; 2 Chinese results were old articles, 0 English results
HN Algolia All four candidates were literal “threads” false matches, excluded
Industry media (EET-China column) No new articles in window; most recent was the 10-24 summit report

Full Source List