Kernel & Embedded News: IPv6 Escape Fix; Apple M3 Boots

This edition is about patching discipline. A fragmentation bug in the kernel’s IPv6 output path (CVE-2026-53362) lets an unprivileged process corrupt kernel memory and, in a container, escape to root; it has now been fixed across seven stable kernel series. Alongside it, the Linux 7.2 merge window brought a measurable MGLRU memory-reclaim improvement and initial Apple M3 boot support, and NXP refreshed its i.MX Yocto BSP to a 6.18-based kernel.

An IPv6 container-escape fix backported across seven stable kernels, an MGLRU reclaim improvement in Linux 7.2, initial Apple M3 boot support, and NXP’s i.MX Yocto BSP moving to a 6.18-based kernel.

The common thread this fortnight is routine maintenance done well: a security fix that every team should apply promptly, two steady improvements landing through the ordinary Linux 7.2 merge window, and a vendor board support package moving to a newer long-term-support kernel. None of these are dramatic, but each changes what a team should do this month.

In this edition

IPv6 container-escape fix reaches stable. A miscalculation in the paged IPv6 transmit path (CVE-2026-53362) that can give an unprivileged user root has been fixed across seven stable kernel series (LWN).
MGLRU reclaim improvement lands in Linux 7.2. Reworked reclaim and dirty-writeback handling raised MongoDB throughput by about 30% on NVMe and up to 100% on slow storage (Phoronix).
Apple M3 boots the mainline kernel. Nearly 1,000 SoC patches in 7.2 include initial, alpha-quality boot support for five 2023-generation M3 MacBook models (Phoronix).
NXP refreshes its i.MX Yocto BSP. The i.MX Yocto guide revision LF6.18.20_2.0.0, dated 25 June 2026, moves the reference BSP to a 6.18-based long-term-support kernel (NXP).

An IPv6 fix you should apply now: CVE-2026-53362

On 4 July, Greg Kroah-Hartman released the 7.1.3, 6.18.38, 6.12.95, 6.6.144, 6.1.177, 5.15.211 and 5.10.260 stable kernels. Two of them carry security fixes; the more serious is CVE-2026-53362, a bug in the kernel’s IPv6 output path.

The defect is in __ip6_append_data() when the paged-allocation branch is taken (the code path used with MSG_MORE, scatter-gather-capable devices, or large fragment lengths). The linear buffer is under-sized by the fragment-gap value while the paged length is over-stated by the same amount, so the copy writes past skb->end into the adjacent skb_shared_info. An unprivileged process can trigger this over a UDPv6 socket using MSG_MORE together with MSG_SPLICE_PAGES.

The reason this matters for embedded and cloud teams is the privilege boundary it crosses. The bug was introduced in the 6.0 kernel, so it is present in a wide range of currently deployed devices and images, and because it needs no special privilege it is a realistic path from an unprivileged container to root on the host. The upstream correction landed on 16 June as commit 736b380e28d0 and is now in the stable series above.

The practical approach is straightforward. Identify every product and image on a 6.0 or newer kernel, confirm the fix is present (by stable version or by cherry-picking the commit into a frozen BSP), and schedule the update. Multi-tenant hosts and any device that exposes container or namespace isolation should be treated as the priority.

MGLRU reclaim improvement in Linux 7.2

The memory-management pull for the Linux 7.2 merge window includes a reworked MGLRU reclaim loop. Kairui Song of Tencent submitted an eight-patch series that improves the reclaim path and dirty-folio writeback handling, as Phoronix reported. In the reported measurements, MongoDB under YCSB gained about 30% throughput on NVMe storage, with slower storage showing gains as high as 100%.

The gain comes from reducing wasted work during reclaim rather than from any new tuning knob, so most workloads inherit it without configuration changes. The same merge also batches the freeing of order-0 pages and tightens mmap_miss accounting, which lowers unnecessary synchronous read-ahead on sparse and strided access patterns.

For teams running database or storage workloads on Linux, this is worth folding into your normal kernel-evaluation cycle rather than acting on immediately. Reclaim behaviour is workload-specific, so treat the headline numbers as an indication and benchmark your own access pattern before and after moving to 7.2. Memory-constrained embedded systems that page to slow flash are the most likely to see a visible difference.

Apple M3 boots the mainline kernel

Nearly a thousand SoC patches were merged for Linux 7.2, and among them is initial support for booting Apple’s 2023-generation M3 hardware, covering five M3 MacBook models. As Phoronix notes, this is alpha-quality: the machines reach a serial console and little more, with no GPU acceleration and non-functional laptop keyboards. The work is the result of the Asahi Linux project’s reverse engineering.

The interesting point here is not desktop usability, which remains far off, but what the milestone shows about bringing a closed, undocumented platform into mainline. Enablement starts at the lowest level — clocks, interrupts, and enough of the boot path to reach a console — and the remaining functionality is added driver by driver over subsequent releases. This is the same shape as bringing any new SoC up in Linux, on hardware with no vendor datasheet.

This item is a curiosity for most product teams rather than something to act on. Its value is instructional: it is a clear, public example of the platform bring-up sequence we teach — from first boot to a usable board — playing out in the mainline tree in real time.

NXP refreshes its i.MX Yocto BSP to a 6.18 kernel

NXP published a new revision of its i.MX Yocto Project User’s Guide, UG10164 revision LF6.18.20_2.0.0, dated 25 June 2026. The revision string indicates the reference BSP now tracks a 6.18-based long-term-support kernel, replacing the older baseline for teams building i.MX images with Yocto.

A vendor BSP moving to a newer LTS kernel is one of the more consequential events in an embedded product’s lifecycle, even though it rarely makes headlines. It changes the security-fix baseline you inherit, the device-tree and driver behaviour you validate against, and the support window you can commit to a customer. Moving to a 6.18 base extends how long the platform receives upstream stable fixes, which directly affects long-lived industrial and medical products.

My recommendation is to plan the migration deliberately rather than defer it. Pin the exact BSP tag in your build, rebuild and run your full validation suite against the 6.18 base early, and record any local patches you carry so they can be rebased cleanly. Teams that let a vendor BSP drift several LTS versions behind usually pay for it later as a large, risky jump under deadline. For engineers who maintain these BSPs, this is exactly the kernel-and-Yocto integration work our embedded Linux training is built around.