Linux 7.0 Released: Rust Goes Stable, XFS Gets Self-Healing, and AI Reshapes the Development Process

Linus Torvalds announced the release of Linux kernel 7.0 on April 12, 2026, marking the latest in the 35-year lineage of the kernel he first published as a student project. The version number jump from 6.19 to 7.0 carries no special architectural significance — Torvalds has explained this before, and reiterated with this release that he simply prefers to roll over to a new major version rather than let the minor version climb past 19 into awkward territory. This is a normal kernel release that happens to wear a round number.

What is not normal is the development context surrounding it. In his release announcement on the Linux Kernel Mailing List, Torvalds noted something worth paying attention to: "The last week of the release continued the same 'lots of small fixes' trend, but it all really does seem pretty benign, so I've tagged the final 7.0 and pushed it out. I suspect it's a lot of AI tool use that will keep finding corner cases for us for a while, so this may be the 'new normal' at least for a while. Only time will tell."

That observation, brief as it is, signals a genuinely new phase in how the Linux kernel is maintained. The features inside 7.0, meanwhile, are substantial: Rust loses its experimental label for good, XFS gains autonomous self-healing capabilities, post-quantum cryptography lands in module signing, critical next-generation CPU groundwork ships for Intel Nova Lake and AMD Zen 6, Intel TSX gets re-enabled by default, and a new in-kernel synchronization driver improves Windows game compatibility through Wine and Proton. Here is the full breakdown.

Why 7.0 Exists: The Version Number Explained

Every few years, someone asks why the Linux kernel jumped from X.19 to (X+1).0 rather than continuing to X.20. The answer is purely aesthetic. Torvalds has said explicitly that Linux version numbers carry no technical meaning — there is no special collection of features or architectural break that triggers a new major version. The rule of thumb is simply that once the minor version reaches 19, the tree rolls over to avoid confusing people with large minor version numbers.

Linux 3.x rolled to 4.0 at the same point. Linux 4.x became 5.0 the same way. Linux 6.x is now Linux 7.0. The features that landed in 7.0 are the same kind that would have landed in a hypothetical 6.20 — the calendar and development cycle determined the content, not the version number. Ubuntu 26.04 LTS, scheduled for release on April 23, 2026 and codenamed Resolute Raccoon, ships with Linux 7.0 as its default kernel, which will bring these changes to a very large portion of the Linux user base through five years of mainstream support and ten with Ubuntu Pro.

Rust Is Now Officially Stable in the Linux Kernel

The single most symbolically significant change in Linux 7.0 is the removal of the "experimental" label from Rust support. The Rust programming language was first introduced into the kernel in 2022 as an explicitly experimental addition, with the understanding that its long-term future would be evaluated at the Linux Kernel Maintainers Summit. That evaluation happened in late 2025, and the conclusion was unambiguous. As Miguel Ojeda, the lead developer of the Rust-for-Linux project, stated: "The experiment is done — Rust is here to stay."

What does this mean in practice? Kernel subsystems and drivers can now be written in Rust alongside C as a fully accepted, first-class part of the kernel development process. Patches implementing kernel components in Rust will no longer be treated as carrying special experimental risk; they go through the same review process as any C code. New drivers and subsystems written in Rust are part of the normal kernel, not a parallel experiment running alongside it.

The deeper significance is what Rust brings to kernel security. The kernel is written almost entirely in C, a language that does not prevent entire classes of memory safety bugs at compile time. Buffer overflows, use-after-free errors, null-pointer dereferences, and race conditions in memory access — these are the most common categories of Linux kernel CVEs year after year. Safe Rust structurally prevents all of them. A buffer overflow in safe Rust is not a programming mistake waiting to be found; it is a compile error that cannot ship. By making Rust a permanent first-class option for kernel development, Linux 7.0 begins a transition toward a more structurally secure kernel over the coming years and decades. It will not happen overnight — C remains the dominant language and will for a long time — but the foundation is now officially in place.

Simultaneously, Linux 7.0 removes support for SHA-1-based kernel module signing schemes, which were already considered cryptographically weak. This is a housekeeping change consistent with the security direction the kernel is moving in.

Post-Quantum Cryptography: ML-DSA for Kernel Module Signing

Linux 7.0 takes its first step toward quantum-resistant security by adding support for ML-DSA (Module-Lattice-Based Digital Signature Algorithm) for kernel module authentication. ML-DSA is a FIPS 204 standard approved by NIST specifically as a post-quantum digital signature algorithm. Three security levels are available in the kernel: ML-DSA-44, ML-DSA-65, and ML-DSA-87, corresponding roughly to security strengths equivalent to AES-128, AES-192, and AES-256 against quantum attack.

Every time a kernel module — a driver, a filesystem, or any other piece of loadable kernel code — is loaded into a running Linux system, the kernel verifies a digital signature on that module to confirm it has not been tampered with since it was signed by a trusted key. Currently, this signing uses algorithms like RSA or ECDSA that a sufficiently powerful quantum computer could break. The addition of ML-DSA support means kernel module signing can now use an algorithm that is secure against both classical and quantum attacks.

The practical urgency of post-quantum signatures for module signing is a "harvest now, decrypt later" concern: nation-state actors and well-resourced attackers are already collecting signed data today with the intent to verify or forge signatures once quantum computers become capable enough. Systems where kernel module integrity matters for security — servers, critical infrastructure, anything running a long-lived deployment — have reason to migrate to ML-DSA-signed modules well before quantum computers become a practical threat. Linux 7.0 provides the technical infrastructure to do so.

XFS Autonomous Self-Healing

For administrators running XFS filesystems — which includes a significant portion of Linux servers, particularly those on RHEL and its derivatives where XFS is the default filesystem — Linux 7.0 brings a genuinely useful operational improvement: autonomous self-healing.

A new xfs_healer daemon, managed by systemd, watches for XFS metadata failures and I/O errors in real time and triggers repairs automatically while the filesystem remains mounted and live. Previously, XFS repair required the filesystem to be unmounted — a disruptive operation for any system that cannot easily take its filesystem offline. The new daemon changes that: errors detected during normal operation are addressed in the background without requiring manual intervention or scheduled downtime.

This is particularly valuable for filesystems that accumulate metadata inconsistencies gradually — a common pattern in production servers that run continuously for months or years. The old model required an administrator to notice degradation, schedule maintenance, unmount the filesystem, run xfs_repair, and remount. The new model handles this automatically in the background, bringing XFS closer to the self-managing behavior that storage administrators expect from modern filesystems.

Intel Hardware: Nova Lake, TSX Auto Mode, and More

Linux 7.0 includes significant Intel hardware enablement across multiple fronts, most of which will matter directly for users running current and upcoming Intel silicon.

Intel TSX Now Defaults to Auto Mode

Intel TSX (Transactional Synchronization Extensions) was disabled by default in the Linux kernel years ago following a series of security vulnerabilities — the Speculative Execution side-channel attacks that made many Intel hardware features dangerous to expose without careful mitigation. With improvements to mitigation in newer Intel CPUs and microcode, re-enabling TSX on hardware that is not affected by those vulnerabilities is now safe and beneficial.

Linux 7.0 changes the default Intel TSX mode from off to auto. In auto mode, the kernel enables TSX only on CPUs where it is safe to do so — modern Intel silicon with the appropriate microcode mitigations in place. Phoronix benchmarks on Intel Xeon 6980P Granite Rapids hardware showed database workload improvements up to 10% with TSX re-enabled, with a notably larger boost in NAMD molecular dynamics simulation. For workloads that use transactional memory operations, this default change delivers real performance gains without requiring any user configuration.

Intel Nova Lake and Diamond Rapids Groundwork

Linux 7.0 ships with day-one enablement groundwork for Intel's upcoming processor generations. Nova Lake (Core Ultra 400 series desktop CPUs, expected late 2026 or CES 2027) and Diamond Rapids (next-generation Xeon server processors) both have foundational driver and detection support in the kernel. Specifically, LPSS (Low-Power Subsystem) drivers and sound support have been added for Nova Lake, and NTB (Non-Transparent Bridge) driver support along with performance event support have been added for Diamond Rapids. Intel's DSA 3.0 accelerators for offloading tasks to dedicated silicon on newer Xeon chips are also included. Intel TSX auto mode, Turbostat L2 cache reporting, and Crescent Island accelerator bring-up are additional Intel changes in this release.

The significance of shipping this groundwork now, while Nova Lake is still pre-release, is that Linux distributions will boot and run cleanly on these CPUs from their very first day of availability. There will be no "waiting for kernel support" period for early adopters of next-generation Intel hardware.

AMD Hardware: Zen 5 Security, Zen 6 Groundwork, and RDNA GPU Prep

AMD hardware support in Linux 7.0 covers three different areas: security improvements for existing Zen 5 hardware, performance monitoring groundwork for next-generation Zen 6, and graphics enablement for upcoming AMD GPU hardware.

KVM AMD ERAPS Support (Zen 5)

For virtualization, KVM now supports AMD ERAPS (Enhanced Return Address Predictor Security), a Zen 5 security feature designed to mitigate Return-Oriented Programming attacks by improving the security of the Return Stack Buffer. In VM scenarios, enabling ERAPS doubles the RSB from 32 to 64 entries, letting guests fully utilize the larger and more secure RSB. This is a meaningful security improvement for anyone running AMD Zen 5 hardware in a KVM-based virtualization environment, including cloud infrastructure and local VM setups.

AMD Zen 6 Performance Events and Metrics

Linux 7.0 adds Zen 6 performance monitoring events and metrics to the kernel's perf subsystem. Zen 6 (codenamed Olympic Ridge for desktop) is AMD's next-generation CPU architecture, currently targeting a 2027 launch. Having its performance monitoring support in the kernel ahead of launch means developers, system administrators, and profiling tools will have complete hardware performance counter access from day one when Zen 6 hardware ships.

Next-Generation AMD GPU Hardware Enablement

The AMD graphics driver in Linux 7.0 enables new GPU IP blocks for hardware that appears to be an upcoming RDNA 4 successor and another RDNA 3.5 variant. AMD has not formally announced these products, so precise product names are not yet public, but the driver-side groundwork is in place. There are also hints of deeper NPU integration in future Radeon hardware visible in the kernel changes, suggesting AMD is planning tighter CPU-GPU-NPU co-operation in upcoming silicon generations. As with the CPU enablement work, having this support in the kernel ahead of product launch ensures clean day-one compatibility.

NTSYNC: Better Windows Game Compatibility on Linux

Linux 7.0 includes a new in-kernel synchronization driver called NTSYNC, which implements NT kernel synchronization primitives — the synchronization mechanisms that Windows applications rely on — directly in the Linux kernel. This matters specifically for gaming on Linux through Wine and Proton (Steam Play), where Windows games running on Linux have historically suffered from frame pacing problems and micro-stutters caused by the overhead of emulating Windows synchronization in user-space.

With NTSYNC in the kernel, Wine and Proton can use native kernel synchronization primitives instead of slower user-space workarounds, reducing latency and improving frame consistency in Windows games running on Linux. This is a meaningful practical improvement for Linux gaming and Steam Deck users, and it has been a long-requested addition to the kernel for the Proton compatibility ecosystem.

Networking: AccECN On by Default and Wi-Fi 8 Groundwork

Two networking changes in Linux 7.0 are worth highlighting. The first is AccECN (Accurate Explicit Congestion Notification) being enabled by default. Standard ECN in TCP notifies the sender about network congestion, but only when a packet is about to be dropped. AccECN provides continuous congestion feedback before packet loss occurs, allowing TCP connections to reduce their sending rate earlier and more precisely. This fixes what Phoronix and other sources describe as a 38-year-old design limitation in TCP's congestion control. With AccECN on by default, Linux systems will make better use of available network bandwidth with fewer packet drops across the full network stack.

The second is the initial implementation of Wi-Fi 8 (802.11bn) Ultra High Reliability (UHR) support landing in the kernel's wireless networking stack. Wi-Fi 8 hardware is not yet commercially available, but the kernel-side infrastructure is in place so that Linux will be ready to support it from day one when hardware arrives. UHR addresses reliability concerns in dense wireless environments, a key focus of the 802.11bn standard.

Additional networking additions include network namespace support for VSOCK sockets in virtual machines, which enables cleaner network isolation in containerized and VM environments, and multiqueue support for the CAKE traffic shaper to improve performance across multiple CPU cores.

Architecture Support: ARM64, RISC-V, LoongArch, SPARC, and DEC Alpha

Linux 7.0 expands architecture coverage in several directions. ARM64 gains support for atomic 64-byte load and store instructions, improving performance on newer ARM silicon that supports these operations natively. RISC-V receives support for the Zicfiss and Zicfilp extensions, which implement hardware-assisted Control Flow Integrity — essentially hardware enforcement of valid code execution paths that makes certain classes of exploit significantly harder. LoongArch, the architecture used in Chinese-designed processors, gains 128-bit atomic compare-and-exchange support and improvements for KVM virtualization with accurate CPUCFG reporting.

On the more exotic end, Linux 7.0 brings new code for SPARC and DEC Alpha CPUs — architectures from the workstation era of the late 1990s that still have small but dedicated communities of users keeping vintage hardware running. These are not mainstream additions, but they reflect the kernel's commitment to supporting a remarkably broad range of hardware.

AI Bug-Finding and the "New Normal" for Kernel Development

The observation Torvalds made in his release announcement about AI tooling deserves more than a passing mention. The Linux kernel's second-in-command, Greg Kroah-Hartman, has been more explicit about the trend. In March 2026, GKH noted that AI tools have become "truly useful" bug-spotters for the kernel maintenance team. He also made a pull request that updated security bug reporting documentation specifically to "tell the AI tools (and any users that actually read the documentation) how to send us better security bug reports as the quantity of reports these past few weeks has increased dramatically due to tools getting better at 'finding' things."

This is a new dynamic. For most of the kernel's history, bugs were found by humans: developers working on related code, power users hitting edge cases, and security researchers doing deliberate audits. AI-assisted static analysis and fuzzing tools are now surfacing a steady stream of corner-case bugs — small issues that human reviewers did not catch but that automated tools find by exploring code paths exhaustively. Torvalds' characterization of this as potentially "the new normal" is worth taking seriously. The 7.0 release cycle saw more small fixes than typical, driven in part by this AI-assisted bug discovery. The fixes were benign enough not to delay the release, but the volume was notable.

The implications extend beyond just finding more bugs. If AI tools continue improving at locating security vulnerabilities in kernel code, the pace of security fix releases may increase. Distributions that stay close to kernel tip will benefit from a more continuously patched codebase. Long-term stable kernels will need to backport more fixes. Security-focused projects will have a stronger argument for tracking mainline more closely. The kernel is entering a development era where AI is a real participant in the quality assurance process, not just a speculative future tool.

Filesystem and Memory Management Changes

Beyond the headline XFS self-healing feature, Linux 7.0 includes several other storage and memory improvements. F2FS (the Flash-Friendly File System used on Android and flash storage) advances its transition to large folios, improving I/O efficiency on flash-based storage. EXT4 gains improved concurrent direct I/O write performance. exFAT receives optimizations beneficial to removable storage workloads.

In memory management, zram — the compressed RAM block device commonly used as a swap partition on systems with limited RAM — now allows compressed pages to be written back to backing storage without decompression, reducing the overhead of zram writeback operations. The swap subsystem adopts a simplified swap table design. These are incremental improvements that add up to meaningfully better performance on memory-constrained systems, including embedded Linux devices, older hardware, and single-board computers.

What Linux 7.0 Means Going Forward

The Linux kernel has a standard release cadence of roughly one version every 8 to 10 weeks, with patch releases in between. Linux 7.1's merge window will open imminently after the 7.0 release, with the first RC expected around April 26 and the stable release targeting mid-June 2026. The 7.1 merge window already has dozens of pull requests queued, continuing the work begun in 7.0 on hardware support, Rust integration, and security improvements.

Ubuntu 26.04 LTS ships with Linux 7.0 and lands on April 23. Fedora 44 will also ship with 7.0. Rolling release distributions like Arch Linux, CachyOS, and Manjaro already have access to the new kernel. Distros on longer release cycles — Debian stable, Linux Mint, and others based on Ubuntu LTS — will receive Linux 7.0 through the standard update channels of those platforms.

For Linux users and administrators, the practical takeaway from 7.0 is one of genuine substance. Stable Rust support means the kernel's security posture will gradually improve as new drivers adopt the language. Autonomous XFS self-healing reduces operational burden for server administrators. ML-DSA post-quantum signing is infrastructure that becomes important before it becomes urgent. Next-gen CPU groundwork means the kernel will be ready for Intel and AMD's 2026 and 2027 hardware on day one. And the shift toward AI-assisted bug discovery means future kernels may arrive with fewer lurking issues than past release cycles managed through human review alone.

Want more Linux kernel news, open-source coverage, and hardware driver updates? Browse our other posts for the latest on Linux development and the broader open-source ecosystem.