Research window: 2026-10-22 08:00 ~ 2026-10-23 08:00 (Beijing time, 24 hours)

Sources: RT-Thread official news API, community forum article API, GitHub (main repo commits / PR / Issue / Releases / tags, RT-Thread-packages organization repos, topic:rt-thread ecosystem search), Google News aggregation (multiple Chinese and English queries, via proxy), HN Algolia, industry media and vendor channel verification (see appendix source list for details)

This Issue’s Index

  • I. Kernel and Version Updates
    • RISC-V ticket spinlock switches to AMO: unlock side no longer goes through LR/SC retries; K1’s SMP configuration is simultaneously raised from 4 cores to 8 cores (10-22)
    • Message queue FIFO jumped by high-priority threads: a two-year-old ticket yields a minimal case that reproduces stably on mainline (10-22)
    • Mainline ends three days of zero commits: 4 commits landed and 3 proposals merged within the window; v5.4.0 still only has a version macro (10-23)
  • II. Security and Stability Follow-up
    • NVMe leaks 4480 bytes per inactive namespace encountered: compliant drives lose about 1.1 MB of kernel heap on every boot (10-23)
    • 9PFS directly trusts the server length field: ASAN out-of-bounds read runs past the 8.3 MB receive buffer; fix proposal opened (10-22)
    • NFS out-of-bounds write defect ticket status unchanged; no claimant and no fix proposal this issue (10-22)
  • III. Official and Community Activities
    • Official news API still stuck in June; no brand-new long-form community articles within the window (10-23)
  • IV. Ecosystem and Vendor Adaptation
    • ESP32-C3/C6 ESP-IDF v6.1 adaptation merged into mainline: RISC-V toolchain also jumps to GCC 15.2 (10-22)
    • GD32VW553 enters the at_device package: RISC-V Wi-Fi 6 plus BLE 5.2 chip can be selected directly via menuconfig (10-22)
    • GD32EmbeddedUI example enters the LVGL package index one day after repo creation; package and repository form a closed loop (10-22)
    • scons –attach crashes directly on Chinese Windows: 4 emoji markers replaced with ASCII (10-22)
  • V. Summary and Trend Observations
    • Trends this issue
    • Limitations and deduplication notes

I. Kernel and Version Dynamics

1.1 RISC-V ticket spinlock switched to AMO: unlock side no longer goes through LR/SC retries, K1 SMP config simultaneously raised from 4 to 8 cores (10-22)

Date: 2026-10-22 17:59 (merge time)　Source: PR #11904, cpuport.c, K1 BSP README

This change lands in libcpu/risc-v/common/cpuport.c, replacing the implementations of both the lock and unlock paths of the ticket spinlock. Previously both sides used an LR/SC loop to perform a read-modify-write on the same word: the lock side incremented the next-ticket number in the upper 16 bits, recombined it with the current-holder number in the lower 16 bits into a single word, and wrote it back; the unlock side likewise went through LR/SC to increment the holder number. The revised comments spell out two failure modes: first, the ticket-acquisition path and an unlock path retrying LR/SC can interrupt each other on the same reservation set, falling into livelock under high-core contention—this is precisely the SMP stall mentioned in the title; second, the unlock’s whole-word read-modify-write overwrites tickets newly claimed during the concurrent period.

The fix changes ticket acquisition to a single-instruction atomic add via amoadd.w.aqrl (AMO cannot fail, so there is no retry to be interrupted), with the ticket increment set to 1 << 16, keeping both 16-bit counters within the low 32 bits—the comment explicitly notes this also holds on RV64, hence the 32-bit-wide amoadd.w rather than amoadd.d. The unlock side drops the atomic read-modify-write entirely: only the holder writes the holder number, so a single 16-bit halfword store performing “increment by one” suffices, preserving concurrently claimed tickets and eliminating LR/SC; each side gains an rt_hw_barrier() to ensure critical-section memory accesses are ordered after observing the other side’s release, and that publication completes before advancing the holder number.

The same proposal changes CONFIG_RT_CPUS_NR in bsp/spacemit/k1 and RT_CPUS_NR in rtconfig.h from 4 to 8, and adds notes to the two K1 READMEs and the support matrix in bsp/README.md, following the order of “fix the lock first, then open up the core count.” Per the current K1 README, the SoC is 64-bit RISC-V with 8 integrated X60 cores and vector extension; the BSP uses device tree, is booted by U-Boot/OpenSBI running in S-mode, and the validation platform is the Banana Pi BPI-F3. The entire proposal spans 6 files with +33/-37—a modest change in size but one touching RISC-V multicore infrastructure.

1.2 Message queue FIFO preempted by higher-priority thread: two-year-old issue yields a minimal reproducer that reproduces reliably on mainline (10-22)

Date: 2026-10-22 13:54 (comment time)　Source: Issue #4940, ipc.c

The old issue from August 2021 was pushed forward again within the window. The issue originally pointed out that message queues and mailboxes cannot guarantee first-in-first-out under RT_IPC_FLAG_FIFO; the maintainer’s reply at the time acknowledged that “there is no locking here, whereas semaphore effectively does locking,” and no fix has landed since. The new comment follows this thread with a minimal reproducer and states it reproduces reliably on mainline.

The reproducer configuration creates a queue via rt_mq_create() with msg_size=4, max_msgs=1, and RT_IPC_FLAG_FIFO: a low-priority thread (20) first performs a blocking receive, and since the queue is empty it hangs at the head of the wait queue; a high-priority thread (10) does not enter the queue wait but instead blocks on a semaphore; the main thread sends a message, and the low-priority thread is removed from the wait queue and enters the ready queue; the main thread then releases the semaphore, making the high-priority thread ready; after the main thread delays to yield the CPU, the high-priority thread runs first and takes that message with a non-blocking receive. The message does not reach the waiter at the front of the queue—FIFO semantics are broken by priority preemption.

The nature of the problem differs from 1.1: it is not a race window but a semantic choice of “dequeue on wake”—once woken, the waiter leaves the wait queue and becomes an ordinary ready thread, after which any higher-priority non-blocking fetch can legitimately take the message it should have received. The comment mentions that uClinux’s approach is to wake without dequeuing, removing from the pending queue only once the lock is actually acquired, which can serve as a reference for a fix. The issue remains open, and there is no corresponding proposal in this issue.

1.3 Mainline ends three days of zero commits: 4 commits land in the window, 3 proposals merged, v5.4.0 still only a version macro (10-23)

Date: 2026-10-23 (verification time)　Source: main repo commit log, releases, tags

The mainline stasis noted in the previous issue was broken within the window: 4 commits landed on 10-22 alone, all brought in by three merged proposals—ESP32-C3/C6 ESP-IDF v6.1 adaptation (07:42 UTC), RISC-V ticket lock and K1 eight-core (two commits at 09:59 UTC), and emoji replacement in tools/attachconfig.py (10:00 UTC). The merge times cluster within three hours from 15:42 to 18:00 (Beijing time), all handled by the same maintainer, presenting as a concentrated review wrap-up.

The version side remains unchanged: the latest release and tag are still v5.3.0 from 09-10, and the 10-17 “Bump version to v5.4.0” commit still contains only the version macro—no release notes, no binaries, and no pre-release tag. At the organizational level, only the main repo and the packages repo saw pushes within the window; the most recent activity times of the remaining repos are unchanged from the previous issue.

II. Security and Stability Follow-up

2.1 NVMe leaks 4,480 bytes per inactive namespace: a compliant drive loses about 1.1 MB of kernel heap on every boot (10-23)

Date: 2026-10-23 01:15 (created)　Source: Issue #11919, nvme.c

Researcher XueDugu filed a kernel heap leak in the NVMe driver at the end of the window. nvme_scan_device() uses the device-controlled nn (Number of Namespaces) from the Identify Controller response as the loop bound, probing each ID from 1 to nn, and each iteration first does rt_calloc for a 4,480-byte rt_nvme_device before sending the Identify command for that ID. Neither failure path returns this memory: nsze == 0 (namespace allocated but not active, a normal response permitted by the spec) takes continue; an Identify command error takes goto _free_res, skipping the free.

Impact per the author’s measurements: under the default configuration of the official qemu-virt64-aarch64 BSP, idle kernel heap with no NVMe attached is 66,941,784 bytes; with a single-namespace drive reporting nn = 1 it is 66,931,592 bytes, which is normal; with QEMU’s stock nvme device it drops to 65,774,912 bytes — QEMU always reports nn = 256 while exposing only 1 namespace, and that response is legal, so 255 inactive IDs each leak 4,536 bytes (including the memheap header), i.e. 1,156,872 bytes, about 1.1 MB, per boot, or 1.8% of the 64 MB kernel heap. Hot-plug and rescan accumulate this linearly; if a device reports a larger nn (e.g. 0xFFFFFF), the loop keeps allocating until the heap is exhausted and the system can no longer boot, with the serial console stalling after hello rt-thread and never printing a prompt.

The author assigns CWE-401 and CVSS 3.1 4.9 (Medium, AV:P), noting that “the 1.1 MB per-boot leak needs no attacker”; only “heap exhaustion causing boot failure” requires a malicious or malformed controller. The defect was introduced by commit 945114fd5 (NVMe support, #9591) on 2024-11-24 and is present in every release since v5.2.0 and in current mainline. The recommended fix is to move this allocation to after the namespace is confirmed valid and add the missing frees on both failure paths, and not to trust nn directly as the bound (cap it by mnan, or use the CNS 02h Active Namespace ID list instead). The ticket is currently untagged and unassigned.

2.2 9PFS trusts the server length field directly: ASAN out-of-bounds read runs through the 8.3 MB receive buffer; fix proposal opened (10-22)

Date: 2026-10-22 19:36 (created)　Source: PR #11918, Issue #11289, dfs_9pfs.c

dfs_9pfs_read() and dfs_9pfs_getdents() contain out-of-bounds reads decoupled from the server reply length; the proposal (+58/-4) touches only dfs_9pfs.c. The root cause is that the byte count returned by p9_transaction() is discarded (passed as RT_NULL), after which the code directly uses the message’s count, each record’s stat_size, and name_len without ever comparing them against the amount of data actually received; as long as the server returns a message with a huge count but a short actual body, the parser reads past the receive buffer. Under normal conditions the skipped . records do not hit the fd->pos >= end exit condition, so the parser can keep advancing.

The author built a fake in-memory 9P server with bsp/simulator (x86-64, ASAN, -fsanitize=address): handshake and Tstat/Topen/Tclunk are answered normally, but Tread returns only an 11-byte message with count falsely reporting about 2 GB, and the area behind the receive buffer is filled with forged . records plus an ASAN poison guard band. Before the fix this triggers AddressSanitizer: use-after-poison, with the read position landing at byte 8,334,515 within the 8 MB heap region and the process ABORTing; after the fix the malicious reply is rejected (returning P9_READ_UNEXPECTED_DATA or -EIO), normal directory parsing is unaffected, and hello.txt and subdir are still listed.

The fix has four steps: both functions pass the actual received byte count into p9_transaction() and verify it is at least P9_MSG_READ_DATA; count is clamped to rx_size - P9_MSG_READ_DATA instead of trusting the message value; getdents validates per record whether the remaining bytes can hold the length field, whether stat_size exceeds the remaining data, and whether name_len exceeds the current record; the read path likewise clamps the actual bytes read (the author specifically notes that got <= set is insufficient, since set itself may exceed the receive capacity). The patch passes git apply --check on the latest master.

2.3 NFS out-of-bounds write ticket unchanged; no claim and no fix proposal this issue (10-22)

Date: 2026-10-22 (checked)　Source: Issue #11917

The NFS client out-of-bounds write covered in the previous issue (nfs_read() trusts the server’s READ3resok.count as the memcpy length, so a single cat can overflow an 81-byte stack buffer) saw only a status refresh during the window; it remains open and unassigned, with no corresponding fix proposal. The same researcher filed the NVMe heap leak (2.1) and the 9PFS out-of-bounds read (2.2) within 24 hours; all three share the common pattern of “device- or server-controlled metadata used directly as a length or bound for memory operations,” and the 9PFS one already comes with a usable containment-style fix. According to the author, the earlier mtd-cfi (#11272) and usbhost (#11287, #11288) issues belong to the same family and have been accepted, so this thread warrants a systematic family-wide audit rather than ticket-by-ticket patching.

III. Official and Community Activity

3.1 Official news feed still stuck in June; no brand-new long-form community articles in the window (10-23)

Date: 2026-10-23 (checked)　Source: RT-Thread official news API, community forum article API

The organization category of the official news API returned 5 items this time, the latest still being the 2026-06-17 “Abu Dhabi Investment Forum,” so it has been silent for over four months; the official news list page is client-side dynamically rendered, so scraping yields only an empty shell, and the API is the authoritative source for news data. The most recent update time among the top community article entries is 10-21 10:08 for “Dual-board collaborative smart terminal based on NS800RT7P65 and ESP32-C3,” which was already handled as an editorial update in the previous issue and is unchanged this time. No new summit, hackathon, or university-program announcements appeared in the window, nor any new release posts from vendor channels.

IV. Ecosystem and Vendor Adaptation

4.1 ESP-IDF v6.1 adaptation for ESP32-C3/C6 merged into mainline: RISC-V toolchain also bumped to GCC 15.2 (10-22)

Date: 2026-10-22 15:42 (merge time)　Source: PR #11870, RT-Thread-packages/esp-idf PR #18

The main-repo proposal recorded last issue as “blocker resolved, on-board validation pending” was formally merged within the window. The change touches 55 files, +4564/-333, in three parts: C3 and C6 each adapted to the ESP-IDF v6.1 compatibility surface (portmacro.h FreeRTOS V11 declarations, sections.ld, port.c, main.c, rtconfig.py, and minor ADC/SPI driver changes); the RISC-V toolchain upgraded from gcc 11.2 (esp-2022r1) to gcc 15.2 (esp-15.2.0_20251204), with corresponding changes to the CI workflow, docker, and tools/ci; and the FreeRTOS-Wrapper changes explicitly split out into a separate proposal.

At merge time the author’s validation was build-level only: all thirteen C3 attachconfig configurations pass on gcc 15.2 plus the esp-idf #18 package, the C6 default configuration compiles and links, and the hardware on-board row reads “pending validation, C3 flash package ready.” In other words, this is a merge gated on build success. The significance for RISC-V is that C3 and C6 are RISC-V cores (unlike the Xtensa-based S2 and S3), and together with the already-merged package-side CONFIG_IDF_RTOS_RTTHREAD switch, this path is now in place from package to main repo, with the remaining risk concentrated on hardware bring-up.

4.2 GD32VW553 added to the at_device package: RISC-V Wi-Fi 6 plus BLE 5.2 chip selectable directly via menuconfig (10-22)

Date: 2026-10-22 09:21 (merge time)　Source: RT-Thread-packages PR #2047, GD32VW553 product page

The at_device package in RT-Thread-packages adds a GD32VW553 entry, +68/-0, consisting of one source line in iot/at_device/Kconfig and a new gd32vw553/Kconfig (67 lines). Configuration options cover the initialization mode (optionally initialized asynchronously by a thread), whether to enable AT socket, and example parameters: network device name defaults to wifi0, SSID and password, AT client device name defaults to uart4, serial baud rate defaults to 115200 (range 9600 to 2000000), receive line buffer length, and reset pin number and active level (-1 means no hardware reset).

The GD32VW553 is a wireless MCU in GigaDevice’s GD32V series; per the vendor product page it has a RISC-V core at up to 160 MHz, integrates 2.4 GHz Wi-Fi 6 (802.11b/g/n/ax, HT20) and Bluetooth LE 5.2, with 4 MB on-chip Flash and 320 KB SRAM, plus DSP hardware acceleration and a double-precision floating-point unit. Making it an AT device means RT-Thread does not drive the radio directly but treats the module as an external network device accessed over UART via AT commands — the same approach as the package’s existing ESP8266, ESP32, EC20, SIM800C and other entries, i.e. a low-cost connectivity path rather than a deep port.

4.3 GD32EmbeddedUI example enters the LVGL package index one day after repo creation, closing the loop between package and repo (10-22)

Date: 2026-10-22 11:17 (merge time)　Source: RT-Thread-packages PR #2048, GD32EmbeddedUI-demos

The GD32EmbeddedUI-demos repo recorded last issue (created 10-21, at the time containing only an Initial commit) was wired into the package system a day later: the LVGL package adds a gd32embeddedui_demos entry, +57/-0, comprising one source line in multimedia/LVGL/Kconfig, a 27-line sub-Kconfig, and a 29-line package.json. The example thus goes from “an empty repo newly created under the org” to a component package selectable in menuconfig, with the source still pointing at the original repo — a lightweight index mount rather than a code copy.

The same batch also includes two package-side updates: [multimedia/LVGL] Add GD32EmbeddedUI demos package (11:17) and [at_device] Add GD32VW553 package configuration (09:21), by the same author and both merged within the window. Taken together, 4.2 and 4.3 show GigaDevice filling in both “connectivity” and “UI” building blocks within 24 hours — a pace that looks more like laying the groundwork for a complete solution than isolated submissions.

4.4 scons –attach crashes outright on Chinese Windows: 4 emoji markers replaced with ASCII (10-22)

Date: 2026-10-22 18:00 (merge time)　Source: PR #11908, attachconfig.py

Four print lines in tools/attachconfig.py used emoji status markers, which makes the entire command unusable on Chinese Windows. The cause is that Python’s stdout encoding follows the locale code page (936/GBK on Simplified Chinese systems), which cannot encode U+2705 and U+274C, so the first print throws UnicodeEncodeError and aborts; since --attach=?, --attach=<name>, and --attach=default all go through the same function, all three paths fail together. Setting PYTHONIOENCODING=utf-8 works around it, but ordinary users would not know that.

The fix replaces the four occurrences with plain ASCII [OK] and [ERR] markers while keeping the existing ANSI color codes — tools/env_utility.py and tools/ci/bsp_buildings.py already use ANSI colored output, so this follows existing convention. The emoji under tools/ci/ were left alone because they are written into GitHub Actions summary Markdown and rendered as UTF-8, unaffected by console encoding. The change touches only 4 print lines with no logic involved; the author did a before/after comparison on Windows 11 Chinese edition with the default code page 936, using the ra6m3-hmi-board directory, currently the only BSP with an attachconfig.yml. This kind of issue does not involve the kernel, but it directly affects the first-time experience for domestic developers.

V. Summary and Trend Observations

  • The RISC-V multicore path received two foundational pieces on the same day: the ticket lock was changed from bidirectional LR/SC retry to “acquire the ticket with AMO, release the lock with a half-word store,” eliminating the livelock surface at its root, and K1 was immediately opened up to 8 cores; meanwhile, ESP32-C3/C6 gained the ESP-IDF 6.1 base and the GCC 15.2 toolchain. The former fixes multicore correctness, the latter fixes the availability of the new base — both are “unremarkable but decisive for how stably things run” work.
  • The mainline shifted from idle to a concentrated wrap-up: after three consecutive days of zero commits, three proposals and four commits were merged within three hours on 10-22. The rhythm looks more like maintainers batching up a round of reviews and handling them all at once than a rebound in development intensity; since v5.4.0 there is only a version macro, indicating the release process has still not started.
  • “Device- or server-controlled metadata as length” has become a family of defects: the same researcher reported three issues within two days — an NFS out-of-bounds write, an NVMe heap leak, and a 9PFS out-of-bounds read — with 9PFS already carrying a convergent fix. The author himself traced this line back to older mtd-cfi and usbhost issues; patching them one by one costs far more than investigating by family.
  • Encoding problems on Chinese Windows are starting to be treated as fixable defects: scons --attach fails entirely because an emoji throws an exception under GBK, a high-frequency pain point for domestic developers. Fixes like this are low in technical sophistication but directly beneficial, and are worth viewing alongside other Windows adaptation items in the toolchain.
  • GigaDevice filled in wireless and UI foundational pieces together: within 24 hours, GD32VW553 entered at_device and the GD32EmbeddedUI example entered the LVGL package — the former a RISC-V Wi-Fi 6 module, the latter a UI example — pointing to a complete solution rather than a single-point commit.

5.2 Limitations and Deduplication Notes

  • This issue covers a 24-hour window (10-22 08:00 ~ 10-23 08:00), a Friday, not a Monday, so no multi-day merge is performed.
  • Deduplication against the previous issue: #11870 was already covered last issue as “blockage resolved, awaiting on-board verification,” so this issue only records the merge result and the verification boundary at merge time; #11912, #11914, #11915, #11917, #11910, and #11911 were already covered last issue, so this issue mentions them only where the status has actually changed (#11917’s status is unchanged, noted in a single sentence only).
  • Industry application channels (industrial, automotive, robotics, embodied intelligence) had no new reports in this window: the Ruixin product line has seen no subsequent version or deployment case since the V1.8.4 release, and there were no new application-type long-form articles on the community article side either, so this issue has no such chapter.
  • Within the window, neither the English nor the Chinese Google News queries returned any valid RT-Thread-related articles; the four hits from HN searches were all literal mismatches on “threads” (Brotli thread pools, iPhone app stores, etc.) and were filtered out by title semantics, not treated as candidates.
  • In the topic:rt-thread ecosystem search, only the zlgopen/awtk repository had pushes within the window; that repository is a general-purpose embedded GUI, and its commits have no specific connection to RT-Thread, so it is treated as ecosystem reference and not listed as a separate entry.
  • At the organizational level, only the main repository and the packages repository had pushes within the window; the most recent activity times of the other repositories match the previous issue; under the anonymous API rate limit, no organization-wide full push verification was performed, and instead the repository commit feed, organization page, and Atom subscription were cross-verified.
  • The official news list page is front-end rendered, so scraping yields only an empty shell; news data is therefore based on the API; the community article API only returns the first several entries, and the latest one is an editorial update of a work already covered in the previous issue.

Appendix: Source Verification Table

Source Verification Result
RT-Thread official news API (organization category) No new items; 5 returned this time, latest still 06-17
Official website news list page Front-end dynamically rendered; scraping yields only an empty shell
Community forum article API No brand-new long-form articles among the first several entries; latest is an editorial update to a piece already covered in the previous issue (10-21 10:08)
GitHub main repo commits 4 in the window, ending the three-day zero-commit streak since 10-19
GitHub main repo PRs 13 updates in the window, 3 merged (#11870, #11904, #11908), 1 newly opened (#11918)
GitHub main repo Issues 1 newly opened (#11919, NVMe heap leak); old issue #4940 got a minimal reproduction
GitHub main repo releases / tags No new releases; latest still v5.3.0 from 09-10
GitHub RT-Thread-packages 2 merged (at_device GD32VW553, LVGL GD32EmbeddedUI demos)
Other repos under the GitHub org No pushes in the window; most recent activity same as previous issue
GitHub topic:rt-thread ecosystem search Only zlgopen/awtk, a general-purpose GUI, not a dedicated update, not included
Google News aggregation (Chinese and English, via proxy) No valid RT-Thread-related articles in the window
HN Algolia All four candidates were literal “threads” false matches, excluded
Industry media and vendor channels No new release announcements or deployment case reports in the window

Full Source List