Linux kernel 6.18 arrived as the last major stable release of the year, bringing a steady, pragmatic blend of performance-focused infrastructure changes, broader hardware enablement, and a handful of contentious maintenance decisions that will shape adoption and packaging in 2026 and beyond. This release reads like the work of a project that prefers careful engineering over headline-grabbing features: improved memory allocators, file‑system hardening and optimizations, Rust driver entries, cryptographic controls for in‑kernel programs, and a visible move to push controversial or slow‑moving subsystems out of the mainline tree. The result is a safe, useful kernel that will benefit servers, laptops, handhelds, and embedded devices alike — though some users and distributions will need to make policy decisions about out‑of‑tree modules, signing, and long‑term support status before rolling it into production.
Linux 6.18 was tagged and released following a routine merge window and a calm release-candidate cycle; maintainers described the merge window as “one of the good ones,” with roughly half the changes being driver work and the rest spread across filesystems, VFS, architecture updates, tooling, and Rust infrastructure. The release’s tone is conservative: extensive bugfixes, performance refinements, and widening hardware support rather than risky, large‑scale redesigns. That approach has won praise in the community — stability-first is the running theme here. Two pieces of context matter for readers planning adoption:
At the same time, new primitives like dm‑pcache and upstreamed NPU drivers show that Linux remains the platform where new architectures and accelerator types are integrated first — and that upstreaming both in‑kernel and userspace components (like Mesa for Rocket) is a key enabler for broader adoption.
For system administrators: test 6.18 in your environment, plan for DKMS or vendor support for any out‑of‑tree modules you rely on, integrate signing into your CI if you plan to rely on signed BPF, and measure the sheaves/SLUB changes against your allocation patterns. For enthusiasts and laptop/handheld owners: expect wider hardware support and improvements to tactile features like haptics and DualSense audio. For distributions and vendors: now is the moment to decide which 6.18 features to enable by default, and whether this kernel will carry an LTS mantle for the next cycle.
Linux 6.18 is not flashy. That is the point: stability, incremental optimization, and measured innovation. The kernel community is shipping work that will make systems faster, safer, and more capable without breaking the world — and that is precisely the kind of engineering that keeps Linux useful in both bleeding‑edge devices and conservative production environments.
Source: theregister.com Version 6.18 of the Linux kernel is here
Background / Overview
Linux 6.18 was tagged and released following a routine merge window and a calm release-candidate cycle; maintainers described the merge window as “one of the good ones,” with roughly half the changes being driver work and the rest spread across filesystems, VFS, architecture updates, tooling, and Rust infrastructure. The release’s tone is conservative: extensive bugfixes, performance refinements, and widening hardware support rather than risky, large‑scale redesigns. That approach has won praise in the community — stability-first is the running theme here. Two pieces of context matter for readers planning adoption:- This is a candidate to become the next Long‑Term Support (LTS) kernel series, and many downstreams are watching closely; that designation is not automatic and will be confirmed separately by the maintainers and the LTS program. Early signs make 6.18 a strong candidate, but it should not be assumed until an LTS appointment is announced.
- A clear policy signal: components judged to have become stale or out of step with mainline practices are being moved out of the in‑tree kernel and maintained externally (DKMS/out‑of‑tree). That has immediate implications for distribution packaging and enterprise signoff processes.
What’s new, at a glance
- Stability and performance: SLUB allocator enhancements via sheaves (per‑CPU cached arrays), several swap and slab-related optimizations, and more efficient VMA and slab code paths promise measurable gains for memory- and allocation-heavy workloads.
- Filesystems: removal of in‑tree bcachefs (moved to DKMS/out‑of‑tree), exFAT allocation bitmap optimizations (large speedups in some scenarios), XFS online check/repair improvements, Btrfs parallelism gains, ext4 functional tweaks, and faster FUSE paths.
- Storage/memory device-mapper target: dm‑pcache enables persistent memory (PMEM) to act as a high‑throughput, crash‑safe write‑back cache in front of slower block devices. This gives sysadmins a new tool to combine byte‑addressable persistent memory and conventional SSD/HDD stacks.
- Security, networking, and observability: preliminary support for signed eBPF programs, AccECN transport protocol hooks (Accurate ECN), and other network improvements aimed at data‑center and congestion‑control use cases.
- Rust in the kernel: a Rust implementation of Android’s Binder IPC arrives, plus a preliminary Rust DRM driver for Arm Mali GPUs (Tyr). These are early but notable steps in the ongoing Rust‑in‑the‑kernel effort.
- Graphics/accelerators: Nouveau defaults to using NVIDIA’s GSP firmware for Turing/Ampere by default, the Rockchip “rocket” NPU driver and userspace Mesa support are upstreamed, and there’s preliminary support for Arm Mali in Rust. Apple M2 device tree and SoC support also continue to improve upstream.
Filesystems: small changes, big operational impact
bcachefs: out of mainline and into DKMS
The most visible and controversial change in 6.18 is the removal of the bcachefs core code from the mainline kernel. What was added in 6.7 as an experimental filesystem and subsequently flagged as “externally maintained” has now been stripped from the tree and is being distributed by its maintainers as an out‑of‑tree DKMS module. For users running bcachefs as a root filesystem this means extra packaging steps (DKMS or vendor module support) and a small but meaningful change in the upgrade story: distributions that refuse to ship out‑of‑tree modules by policy will not include it by default. Operationally, the filesystem remains usable, but the maintenance and QA promises shift from the kernel project to the bcachefs project and distribution packagers. Why this matters: shipping a filesystem as an out‑of‑tree DKMS module is workable, but it reduces the “it just works” seamlessness that mainline inclusion provides (automatic rebuilds via DKMS still mitigate much of this). For enterprise environments that require fully vetted in‑tree code, this is a break in the mental model of the kernel as the single authoritative source of filesystem support.exFAT: dramatic allocation bitmap optimization
The exFAT code saw a specific optimization to how allocation bitmaps are loaded, which in benchmarks on large partitions with small cluster sizes produced dramatic speedups — Phoronix reported results in the order of roughly 16× faster loading times in some scenarios. This is directly relevant to devices that rely on SD cards or microSD (camera, mobile, embedded storage) and will reduce mount latency and I/O overhead in those use cases.XFS: online checks and more practical server operations
XFS continues to expand its online scrub and repair capabilities; the goal is to let administrators check and repair metadata on mounted XFS volumes without taking servers offline. For very large storage volumes — where offline checks are operationally expensive — being able to scrub and repair while mounted is a material availability win. The XFS online‑fsck effort has been in development for a while and is becoming production‑ready.FUSE and user‑space filesystems: lifted limits and virtio‑fs tuning
FUSE’s interfaces were modernized to offer full 64‑bit copy_file_range support and better virtio‑fs handling, which helps large‑data user-space filesystems and virtualization scenarios. These are practical changes that reduce friction when running large datasets or virtualization workloads with filesystem forwarding.Memory, allocators, and the sheaves story
The kernel’s slab allocator has evolved significantly. The SLUB patches introducing sheaves (per‑CPU array caches) plus the barn (a per‑NUMA pool for sheaves) aim to reduce contention and improve allocation/free latency for workloads that allocate many small objects. Sheaves make many allocations into simple local pointer operations instead of lock/atomic paths, and include features like improved kfree_rcu handling and preallocation support for guaranteed allocations. Benchmarks reported with the patch series show real-world gains in allocation-heavy code paths and better scaling on multi‑CPU systems. This is the most substantial memory‑subsystem change that will affect high‑scale servers and databases. What to watch for: large allocator changes can have surprising micro‑regressions for corner workloads; the patch set is opt‑in per cache today, and kernel developers are carefully phasing it in. That opt‑in model gives distributions and downstreams room to test before enabling wide rollout.dm‑pcache: persistent memory as a cache layer
dm‑pcache is a new device‑mapper target that uses DAX‑capable persistent memory (PMEM) as a fast, crash‑persistent write‑back cache in front of conventional storage. It is designed for high throughput and low latency, with features like CRC verification of data and multi‑tree indexing for parallelism. For systems that have byte‑addressable persistent memory (Optane‑like devices or other PMEM), dm‑pcache provides a flexible way to accelerate slower block devices while preserving crash consistency. Operational note: PMEM remains relatively niche hardware in many environments. dm‑pcache is a powerful primitive for those who can deploy it, but it also introduces complexity in capacity planning and testing. Storage administrators should test failure modes (power loss, metadata corruption) carefully before trusting dm‑pcache in production.Graphics, accelerators, and input: more hardware support
- Nouveau + NVIDIA GSP: Nouveau will use NVIDIA’s GPU System Processor (GSP) firmware by default for Turing and Ampere GPUs, improving reclocking and power behavior by aligning the default path with what distributions like Fedora already ship. Users without firmware can still fall back to the older code path, but distro packagers need to ensure the GSP firmware is shipped where policy allows.
- Rust Mali driver (Tyr): The experimental Rust DRM driver for Arm Mali GPUs (Tyr) landed in an initial form. It’s functional for basic GPU power management and metadata queries but is explicitly preliminary. This is a promising sign of Rust’s incremental role in kernel graphics drivers.
- Rockchip NPU “Rocket”: The kernel component for the Rockchip NPU (RKNN) and the Mesa userspace Rocket Gallium driver are upstreamed, enabling machine‑learning acceleration on boards like the RK3588 without blob drivers. This is a welcome step for embedded and edge inference workloads.
- Input and laptops: Improvements cover DualSense audio jack hot‑plug detection and haptics, haptic touchpad groundwork, and additional ACPI/WMI hooks for laptop vendor features (Dell/Alienware, HP Omen, multiple ASUS ROG motherboards). Those changes improve out‑of‑the‑box support for many modern gaming laptops and handhelds.
Security and networking: signed eBPF and AccECN
Signed eBPF programs
A major security/operational feature arriving in 6.18 is preliminary support for signing eBPF programs and handling signatures in libbpf/bpftool. The intent is to give system owners and security policies the ability to trust and require only vetted eBPF code to be loaded into the kernel, thereby enabling safer delegation of certain observability or networking tasks to unprivileged tooling. The implementation adds APIs and loader hooks to pass signatures and validate them against kernel keyrings. Implications and risks:- This can improve security by enabling policies that restrict which eBPF programs can run on a host.
- It also introduces policy complexity: organizations will need key management for signing and processes for permitting unsigned or third‑party programs.
- There is a potential for operational friction if vendor tooling or third‑party instrumentation doesn’t integrate with signing workflows out of the box.
AccECN network hooks
AccECN (Accurate Explicit Congestion Notification) is a new TCP feedback mechanism designed to send richer congestion signals back to senders. The kernel trees picked up the protocol patches and negotiation code, and the IETF finalized AccECN (RFC 9768) in 2025. These changes are oriented toward advanced congestion control schemes used in data centers and for L4S-type applications. Network engineers should treat AccECN as an emerging capability that requires end‑to‑end support to be useful. Until both endpoints and middleboxes understand AccECN semantics, default behavior will be conservative.Rust in the kernel: Binder and beyond
After multi‑year work, a Rust version of the Android Binder driver has been merged. Binder is a critical IPC component for Android’s security model, and a Rust rewrite aims to reduce memory‑safety exposure in one of the kernel components that historically has been fertile ground for vulnerabilities. The Rust driver is designed to be functionally compatible with the existing C implementation while using Rust’s safety features for better maintenance and fewer classes of bugs. Caveats: the presence of a Rust driver in mainline is a milestone, but the ecosystem impact will be gradual — tooling, auditing, and driver maturity need continued attention.Distribution uptake and LTS prospects
Rolling‑release distributions (Arch, openSUSE Tumbleweed, Fedora Rawhide) will carry 6.18 quickly; enterprise distros take more measured positions. As of the release, the kernel is a candidate to become the next LTS release — a designation that matters for enterprises, embedded vendors, and distributions — but LTS appointment is a separate announcement and practice. Distributions like Debian and RHEL are conservative about packaging brand‑new kernels; Ubuntu’s HWE and interim channels usually adopt newer kernels faster, and Ubuntu 26.04 LTS (and its snapshots) will be watched for inclusion plans. Until the LTS designation and packagers’ decisions are published, administrators should treat 6.18 as production‑ready but not compulsory for broad rollout.Practical upgrade guidance (for sysadmins and enthusiasts)
- Test before mass deployment — run representative workloads and exercise unusual paths (device drivers, in‑tree vs out‑of‑tree modules).
- Vendor drivers and DKMS: if you rely on bcachefs, plan for DKMS builds and initramfs integration; test boot paths and verify recovery procedures.
- eBPF signing strategy: define whether you’ll require signed BPF programs. If you have CI jobs that generate eBPF artifacts, incorporate signing into the pipeline.
- PMEM and dm‑pcache: validate cached I/O semantics and failure scenarios before enabling in production.
- Graphics and firmware: for Nouveau/GSP or other firmware‑dependent drivers, ensure your distro’s firmware packaging (and firmware license policy) matches the new defaults.
Critical analysis — strengths, concerns, and unanswered questions
Strengths
- Practical engineering wins: SLUB sheaves, dm‑pcache, XFS online repair, and exFAT bitmap optimizations are the sort of changes that produce measurable benefits for real systems without requiring risky API churn. They target performance, availability, and user‑perceived latency — the day‑to‑day metrics that matter.
- Security posture improvements: signed eBPF and the use of Rust in safety‑sensitive drivers reduce attack surface and give operators more tools to enforce trust.
- Broad hardware enablement: upstreaming NPUs, Apple M2 device trees, and more laptop vendor WMI hooks mean fewer vendor kernels and better long‑term maintainability for hardware.
Risks and downsides
- Out‑of‑tree bcachefs fragmentation: removal of bcachefs from mainline is a risk to long‑term portability and discoverability. DKMS works, but it shifts responsibility for critical fixes and packaging to a smaller team and the distro community. For some enterprise distros with strict policy about out-of-tree modules, bcachefs may become harder to deploy.
- Operational complexity from signed BPF: signing introduces key management, change control, and possible integration work for third‑party modules and telemetry stacks. Organizations will need to standardize workflows to avoid friction.
- Rust drivers are early stage: while Rust drivers reduce memory-safety issues, they are new and sometimes smaller in features compared to long‑standing C counterparts. Expect incremental feature parity work and careful testing before relying on them for critical workloads.
- Sheaves and allocator changes: allocator changes can expose corner‑case regressions in peculiar workloads; although the sheaf model is opt‑in and benchmarked, downstreams will want careful validation on large cluster workloads.
Unverifiable or conditional claims flagged
- Whether 6.18 will be the official LTS series is widely expected by many commentators, but the LTS appointment is a distinct governance decision that must be confirmed by relevant maintainers; treat that as pending until announced.
How this release fits into the longer trend
Linux continues on a pragmatic path: incremental, focused improvements in core OS components (memory allocators, filesystems, device trees), cautious but real expansion of Rust usage, and greater tooling for runtime trust (signed eBPF). The kernel tree is balancing two tensions: the desire for broad upstream hardware support and the need to keep the mainline codebase maintainable and well-reviewed. The removal of bcachefs is an example of that balancing act: mainline inclusion is no longer a guaranteed home for ambitious projects without sustained upkeep and cooperation with the kernel maintainers.At the same time, new primitives like dm‑pcache and upstreamed NPU drivers show that Linux remains the platform where new architectures and accelerator types are integrated first — and that upstreaming both in‑kernel and userspace components (like Mesa for Rocket) is a key enabler for broader adoption.
Conclusion
Linux 6.18 is a pragmatic, solid release that rewards careful reading and testing rather than breathless adoption. It brings meaningful wins — faster exFAT mounts for large flash media, online XFS checks for heavy server farms, sheaves that can reduce allocator contention, and a path for PMEM caching that could change storage stack tradeoffs. At the same time, it surfaces governance and operational choices: bcachefs’s removal from mainline, eBPF signing policy work, and the continued incremental arrival of Rust drivers all require downstream policy and packaging decisions.For system administrators: test 6.18 in your environment, plan for DKMS or vendor support for any out‑of‑tree modules you rely on, integrate signing into your CI if you plan to rely on signed BPF, and measure the sheaves/SLUB changes against your allocation patterns. For enthusiasts and laptop/handheld owners: expect wider hardware support and improvements to tactile features like haptics and DualSense audio. For distributions and vendors: now is the moment to decide which 6.18 features to enable by default, and whether this kernel will carry an LTS mantle for the next cycle.
Linux 6.18 is not flashy. That is the point: stability, incremental optimization, and measured innovation. The kernel community is shipping work that will make systems faster, safer, and more capable without breaking the world — and that is precisely the kind of engineering that keeps Linux useful in both bleeding‑edge devices and conservative production environments.
Source: theregister.com Version 6.18 of the Linux kernel is here
