Kernel & Embedded News: Silent Data-Loss Bug Fixed; CRA Reporting Live

Two items this week call for direct attention: a data-corruption fix that affects every x86 kernel since 6.6, and a European reporting obligation that is now in force. The other four are planning signals — stable-kernel patch volume has reached a record, Yocto has frozen the feature list for its next release, U-Boot has moved to new project infrastructure, and kernel build times are set to drop.

In this edition

• Silent data loss fixed after three years — on x86, writes made after an MADV_FREE call to huge pages could vanish under memory pressure; the one-line fix is headed to every stable series. — patch when your branch picks it up
• CRA vulnerability reporting is now mandatory — since 11 September, manufacturers selling into the EU must report actively exploited vulnerabilities within 24 hours. — act now
• A record stable wave: more than 9,000 patches in one day — seven point releases at once, with maintainers describing heavy AI-generated patch volume. — process signal for LTS consumers
• Yocto 6.1 reaches feature freeze — the release building now carries OpenSSL 4, rpm 6, clang 23.1.0 and the 7.2 kernel. — planning signal
• U-Boot moves its infrastructure ahead of v2026.10 — rc4 is out, the old lists server is shut down and source.denx.de redirects to git.u-boot-project.org; the final release is due on 5 October. — check your pinned URLs
• Kernel builds set to get a third faster — a 23-patch series removes single-threaded bottlenecks in the build process, aimed at Linux 7.4. — worth testing

A silent data-loss bug, present since Linux 6.6, is fixed with one line

On 2 September, Orson Peters, a developer of the Polars data-analytics library, posted a short C reproducer to the kernel’s memory-management list: fill a buffer, call madvise(MADV_FREE), write the buffer again, and under cgroup memory pressure the second write can disappear. Later reads return zero-filled pages, with no error reported anywhere. Polars users had already lost production data this way.

Vernon Yang identified the cause within a day. Since the x86 shadow-stack preparation work that shipped in Linux 6.6, pmd_modify() has stripped the hardware dirty bit from PMD-mapped transparent hugepages. Memory reclaim then finds a lazy-freed folio with no dirty bit set anywhere and discards it, even though the application rewrote the data after the MADV_FREE call. NUMA balancing can trigger the same loss on its own, and PMD-mapped file THPs can silently miss writeback.

The fix restores _PAGE_DIRTY to the preserved mask — one changed line in arch/x86/include/asm/pgtable.h. Rick Edgecombe, author of the original shadow-stack series, reviewed it and confirmed the stripping was an unintended leftover, and a SUSE engineer reported an independent customer case that the patch resolved. It was merged into mainline after 7.3-rc3 and is tagged for the stable trees. Every x86 kernel from 6.6 to the current 7.3 release candidates carries this bug; arm64 devices are not affected.

The trigger conditions read narrow — huge pages, MADV_FREE, reclaim pressure — but they describe ordinary modern deployments. Memory allocators issue MADV_FREE on their own, and cgroup memory limits are standard under systemd and in containers. x86 industrial PCs, edge gateways and build servers are all in scope.

How to check your device

You are exposed if the machine is x86, runs kernel 6.6 or newer, has transparent hugepages enabled, and runs any software that calls MADV_FREE — memory allocators are the usual source. Two commands answer the first three questions:

raghu@techveda.org:~$ uname -rm
6.12.110 x86_64
raghu@techveda.org:~$ cat /sys/kernel/mm/transparent_hugepage/enabled
always [madvise] never

If the bracket sits on always or madvise, plan the update. The fix is tagged for stable, so expect it in the next rounds of 6.6.y, 6.12.y, 6.18.y and 7.x.y point releases — take the whole point release rather than the single patch. Until it lands, booting with transparent_hugepage=never removes the trigger, at a measurable performance cost. arm64 fleets need no action on this one.

CRA reporting is no longer a future obligation

Article 14 of the Cyber Resilience Act, Regulation (EU) 2024/2847, began to apply on 11 September 2026. From that date, a manufacturer of a product with digital elements sold in the EU must report an actively exploited vulnerability in the product, or a severe incident affecting the product’s security, through ENISA’s Single Reporting Platform — which went live the same day. One submission reaches both the coordinating national CSIRT and ENISA.

The deadlines are short. An early warning is due within 24 hours of becoming aware, a fuller notification within 72 hours, and a final report within 14 days for an actively exploited vulnerability once a corrective measure is available, or within one month for a severe incident. The bulk of the CRA — the essential cybersecurity requirements and CE marking — applies from December 2027, but the reporting duty is in force now, with penalties of up to €15 million or 2.5% of global turnover.

A legal deadline presupposes detection. A team cannot file an early warning within 24 hours for a vulnerability it learns about weeks late, so monitoring the kernel CVE feed for the exact version a product ships, tracking vendor BSP advisories, and keeping an accurate SBOM stop being internal good practice and become inputs to a statutory deadline. Our weekly kernel CVE roundups and the support-clock analysis describe the monitoring side of exactly this problem.

What it means for manufacturers

• Confirm scope first: the obligation attaches to the manufacturer of a product with digital elements placed on the EU market, wherever the manufacturer is based. An India-based device maker exporting to the EU is covered.
• Route vulnerability intelligence — the kernel CVE feed filtered to your shipped versions, plus vendor advisories — into a channel someone is responsible for watching, not into an individual inbox.
• Assign the 24-hour reporting duty to a role with backup coverage, and register on the Single Reporting Platform before the first incident, not during it.
• Run one internal dry run of a report so the first real submission is not a first attempt.

Seven stable kernels, more than 9,000 patches, one Monday

On 14 September Greg Kroah-Hartman released seven stable kernels at once — 7.2.6, 6.18.52, 6.12.110, 6.6.157, 6.1.188, 5.15.221 and 5.10.270 — carrying more than 9,000 patches between them. He noted the batch may set a record for patch count; 7.2.6 alone contains more than 1,800 patches.

The volume has a context. In the 7.3 networking pull, Jakub Kicinski, who maintains the networking trees with Paolo Abeni, counted 632 net and 648 net-next patches for the cycle and estimated that a third to half of the net-next patches appeared to be AI-driven low-priority fixes, clean-ups and clarifications. He described the maintainers as “completely overwhelmed”, noted that Meta funded enough LLM access to run each incoming patch past several frontier models as a review aid, and said the next step is pointing the tools at process work — managing patchwork, editing commit messages, applying patches already reviewed by trusted people.

Machine-assisted bug finding is filling the stable queues faster than human review capacity grows. Patch count is not risk count — most of these changes are small, machine-found and low severity — but the practical consequence for anyone consuming LTS kernels is that point releases are getting larger while the weekly cadence stays the same. Skipping releases now builds a bigger, riskier delta than it did a year ago, and vendor kernels that cherry-pick individual fixes fall behind the stable tip faster.

What it means for teams consuming LTS kernels

• Take whole point releases on a fixed schedule instead of accumulating a backlog; the cost of catching up is growing quarter by quarter.
• Put the effort into automated boot and workload regression tests. Reading 1,800 patches per release is not a realistic review strategy for a product team.
• When evaluating a vendor BSP, ask how it consumes stable updates — full point releases or selected backports — and how far behind the stable tip it currently is.

Yocto 6.1 freezes: OpenSSL 4, rpm 6, kernel 7.2

The Yocto Project’s weekly status reports place YP 6.1 at Milestone 3 feature freeze, with the M3 build due for release in the week of 14 September and the 6.1.0 release scheduled for the week of 2 November. The stated merge intent for M3 is rpm 6, OpenSSL 4, clang 23.1.0 and the 7.2 Linux kernel. On the stable side, 6.0.3 for the Wrynose LTS has been released, 5.0.20 is in QA, and 6.0.4 is planned for mid-October.

The OpenSSL jump is the item to plan around. OpenSSL 4.0, released on 14 April 2026, removes ENGINE support along with other legacy interfaces. Anything in a layer stack that still loads an OpenSSL engine — afalg or devcrypto for kernel crypto offload, a vendor’s hardware crypto engine, an older PKCS#11 engine build — stops working; the provider API is the replacement. Yocto 6.1 is where much of the embedded ecosystem meets that removal for the first time.

The status reports also record that changes to GitHub’s bot and AI protection disrupted the project’s CI, and that AI scrapers continue to consume significant sysadmin time and money — the same pressure the kernel’s own infrastructure reported two weeks ago. Defending infrastructure from automated crawlers is now permanent work for community build systems.

What it means for Yocto-based products

• Most product teams will stay on 6.0 Wrynose LTS, and what that LTS does and does not maintain still applies — but 6.1’s package set is the version baseline the ecosystem targets next. Treat it as the preview of your next migration.
• Search your layers now for OpenSSL engine usage: ENGINE_ API calls, openssl engine invocations, and afalg/devcrypto/pkcs11 engine configuration. Every hit is migration work toward providers.
• If you consume package feeds, note the rpm 6 move; if you track linux-yocto, the 6.1 baseline is kernel 7.2.

U-Boot: one release candidate left, and new project infrastructure

Tom Rini released U-Boot v2026.10-rc4 on 7 September, carrying platform updates for Marvell, NXP Layerscape/QorIQ, i.MX, AMD/Xilinx, Renesas R-Car, Rockchip and STM32, plus fixes in the EFI loader, FPGA, DFU and networking code. One more release candidate is expected in two weeks, and the final v2026.10 release is scheduled for 5 October.

The announcement also records the next stage of the project’s infrastructure migration. The old lists.denx.de server has been shut down, and source.denx.de/u-boot now redirects to git.u-boot-project.org/u-boot, where the git tags and release archives are published. Account registration on the new server will move from open to closed, and the project states it is not planning a web pull-request model — patches stay on the mailing list.

The redirect keeps existing fetches working today, but the project has not said how long it will remain in place. U-Boot is pinned by URL in a large number of places that outlive any one server: Yocto SRC_URI entries, Buildroot custom-repository settings, repo manifests, and CI mirror configurations.

How to check your build

• Search your layers, manifests and CI configuration for the old hostnames and update the pins to git.u-boot-project.org at the next planned change:

  raghu@techveda.org:~$ grep -rn "denx.de" layers/ manifests/ .gitlab-ci.yml

• If a rebase to v2026.10 is on your roadmap, begin board testing on rc4 now — only one release candidate remains before the 5 October release.
• Bookmark the release archive location under git.u-boot-project.org; scripts that scrape the old paths will eventually stop working.

Kernel builds are set to get a third faster

Lorenzo Stoakes of Arm posted a 23-patch series on 8 September that removes single-threaded bottlenecks across the kernel’s build plumbing — kallsyms, modpost, objtool, mksysmap and the Rust build — followed by a second revision on 14 September. The measured results: full allmodconfig builds around 36% faster, incremental builds up to 70% faster, and no-op rebuilds around 90% faster. Two of the patches are already merged, and the rest are aimed at Linux 7.4.

The method deserves attention alongside the numbers. An LLM was used to locate the bottlenecks and generate first-draft code — Stoakes wrote that it produced “a lot of code, much of it hideous” — after which he audited and rewrote it, verified correctness and performance manually, and marked every commit with an Assisted-by tag. In the same week that networking maintainers described being overloaded by machine-generated submissions, this series shows the same tools producing reviewable, wanted work. The difference is the position of the human: an expert applied the tool to a problem he owns and audited every line, instead of passing unreviewed output to someone else.

How to use it

• Product kernels need no action; if review holds, the improvement arrives with the 7.4 build system, and faster CI follows from upgrading.
• Developers doing iterative kernel work can apply the v2 series to a test tree today and measure their own incremental build times — that is the case the 70% figure describes.
• The tagging convention is worth copying: an explicit Assisted-by record on machine-assisted commits keeps the review honest and the history auditable.

References

• MADV_FREE data-loss bug report and reproducer (linux-mm)
• Fix: x86/mm: Fix pmd_modify() dropping the dirty bit
• Regulation (EU) 2024/2847 (Cyber Resilience Act), EUR-Lex
• CRA reporting in force, 11 September 2026
• Seven stable kernels, more than 9,000 patches
• Networking pull request for 7.3 (Kicinski)
• Yocto Project status, 1 September 2026 (WW36)
• Yocto Project status, 8 September 2026 (WW37)
• OpenSSL 4.0 final release announcement
• U-Boot v2026.10-rc4 announcement
• U-Boot release cycle and schedule
• kbuild speedup series v2 (Lorenzo Stoakes)
• Build-speedup numbers for v2

— Raghu Bharadwaj