The EU Cyber Resilience Act’s vulnerability-reporting duties begin in September, RISC-V consolidates its ratified specifications around the RVA23 baseline, Linux 7.2 teaches khugepaged to build multi-size huge pages automatically, and the hung-task counter becomes resettable at runtime.
This edition is about the rules and reference points that embedded work increasingly has to align with. Two of the items are about standards and specifications settling into a usable form, one is a concrete memory-management change arriving in Linux 7.2, and one is a small operational improvement. The common thread is that the ground under embedded products is becoming more defined, in regulation, in hardware baselines, and in how the kernel manages memory, and each of these changes a decision you will make on your next project.
In this edition
- EU Cyber Resilience Act reporting duties start on 11 September 2026. Manufacturers of connected products must report actively exploited vulnerabilities to ENISA and national CSIRTs, ahead of the full obligations in December 2027.
- RISC-V consolidates its ratified specifications. RISC-V International launched a central library of ratified specifications and the RVA23 profile now defines a stable application-processor baseline.
- Linux 7.2 makes multi-size huge pages automatic. Nico Pache’s work lets khugepaged collapse memory into mTHPs below the PMD size, extending transparent huge pages to more workloads.
- The hung-task counter becomes resettable. The kernel can now reset hung_task_detect_count at runtime by writing zero to the sysctl, which simplifies long-running system monitoring.
EU Cyber Resilience Act reporting duties start on 11 September 2026
The EU Cyber Resilience Act entered into force on 10 December 2024, and its main obligations apply from 11 December 2027. The date that matters first is 11 September 2026, when the reporting obligations begin. From that point, manufacturers of products with digital elements must report actively exploited vulnerabilities and severe incidents to ENISA and the relevant national CSIRT within tight deadlines.
This applies directly to embedded work. Any hardware or software that connects, directly or indirectly, to a network is a product with digital elements, which covers industrial controllers, gateways, medical devices, consumer hardware, and the embedded systems inside them. The Act requires secure design, vulnerability handling across the product lifecycle, security updates, and a software bill of materials in a machine-readable format such as SPDX or CycloneDX.
The kernel side of this is already moving in a helpful direction. After a run of page-cache privilege-escalation flaws found with the assistance of large language models, maintainers have started to remove interfaces that are hard to keep safe, including zero-copy support in the AF_ALG crypto interface, and LWN has covered the case for removing splice() and vmsplice() entirely. A smaller attack surface in the upstream kernel is one less thing for a product team to defend.
My recommendation is to treat September 2026 as the real deadline, not 2027. Stand up SBOM generation now on whatever build system you use; the Yocto sbom-cve-check class produces SPDX with package URLs and is the natural starting point. Put a vulnerability-monitoring and reporting process in place, and make sure every shipping product has a field-update mechanism. That work takes the longest to get right and is independent of the rest of the schedule.
RISC-V consolidates its ratified specifications
RISC-V International has spent the last two years ratifying a large number of specifications, and in May 2026 it launched a centralised library that brings the ratified documents into one place. Alongside the document cleanup, the RVA23 profile now defines a stable application-processor baseline: a fixed set of mandatory extensions, including vector and hypervisor support, that software can assume is present.
For embedded teams the profile matters more than the library. Software portability has been the weakest part of the RISC-V story, because every chip could implement a slightly different set of extensions, which forced per-device kernel and userspace builds. A named baseline lets distributions, toolchains, and the mainline kernel target one well-defined platform, and it lets you compare two SoCs against a single yardstick.
The practical approach when you evaluate a RISC-V SoC for a product is to ask whether it is RVA23-compliant. Compliance is a reasonable predictor of how cleanly a standard distribution and a mainline kernel will run on the part, and how much vendor-specific carrying you will have to do over the product’s life. RVA23-class hardware is beginning to reach the market, so this is now a question you can actually put to a vendor.
Linux 7.2 makes multi-size huge pages automatic
On the kernel side, LWN reported that the 7.2 cycle is expected to include a change, contributed by Nico Pache, that extends khugepaged to create multi-size transparent huge pages automatically. Until now the khugepaged thread only collapsed memory into PMD-size huge pages, typically 2MB; the new work lets it build smaller mTHPs as well, sized to what the process actually uses.
The benefit is better use of the translation lookaside buffer with less waste. Recent processors can cover eight contiguous pages on x86, or sixteen on Arm, with a single TLB entry, so a correctly sized mTHP increases address-translation coverage and reduces page-table walks. Smaller mTHPs are also easier to allocate than a full 2MB page on fragmented memory, and they avoid the internal fragmentation that a partly used PMD-size page causes.
The series adds safeguards against “creep”, where the collapsed size would otherwise drift upward on each scan until it reached the PMD size regardless of real usage; for non-PMD sizes the max_ptes_none knob is restricted to zero or 511. The patches are in linux-next and are expected in the 7.2 merge window.
For embedded teams running memory-heavy workloads on capable Arm or x86 cores, such as edge inference, media pipelines, or busy gateways, this is a performance improvement that needs no application changes. I recommend measuring it on your actual workload once you move to a 7.2-based kernel, because the gain depends on access patterns, and tuning the per-size huge-page controls rather than assuming the defaults suit your memory profile.
The hung-task counter becomes resettable
A smaller operational improvement is worth noting because it affects how you run systems in the field. Since Linux 6.13 the kernel has exposed a counter of how many tasks have hung since boot, at /proc/sys/kernel/hung_task_detect_count. Recent work merged through the memory-management tree lets you reset that counter at runtime by writing zero to the same file.
The hung-task detector flags tasks stuck in an uninterruptible state for too long, which on embedded systems usually points to a driver deadlock, a stalled I/O path, or a storage device that has stopped responding. The counter gives monitoring a simple signal to watch, but until now it only ever increased, so after applying a fix you had to remember the previous value to tell whether the problem had recurred.
Being able to zero it removes that friction. The practical use is straightforward: after a live kernel update or a configuration change intended to address earlier hangs, reset the counter and watch whether it climbs again, without rebooting the device. For fleets of long-running embedded systems where a reboot is disruptive, this makes hang monitoring cleaner. If you already collect this counter in your telemetry, fold the reset into your remediation runbook so a cleared count reliably means a fresh observation window.
References
- European Commission — The Cyber Resilience Act
- European Commission — Cyber Resilience Act: Reporting obligations
- LWN.net — Splicing out vmsplice()
- RISC-V International — Ratified Specifications
- Design & Reuse — RISC-V International ratifies 40 specifications in two years
- LWN.net — Automatic mTHP creation in 7.2
- Phoronix — Linux’s Hung Task Detector Will Be Able To Be Reset
— Raghu Bharadwaj
