If you manage Linux servers in 2026, the release of Linux Kernel 7.0 in April is not just a version number worth noting — it's a meaningful upgrade for your security posture.

Linux kernel 7.0 is now available, featuring stable Rust support and updates to filesystems, networking, virtualization, and security.

While Linus Torvalds was characteristically understated about the release, the security improvements packed into this kernel are anything but routine.

Linux kernel 7.0's new version number should not be mistaken for a major turning point in the kernel's development — the move from 6.19 to 7.0 is largely a numbering reset once the minor version climbed high enough, not a sign of some unusually disruptive release.

But what's inside the box is what matters. From post-quantum cryptography and deprecated hash algorithm removal to surgical sandboxing fixes and smarter io_uring controls, Kernel 7.0 delivers a genuinely stronger baseline for production Linux environments.

This guide breaks down every major security feature in Linux 7.0, explains why each one matters, and tells you exactly what to enable, configure, or audit right now.

Why Linux Kernel 7.0 Is a Security Milestone

Adhering to the established non-LTS cadence, this iteration remains primarily dedicated to fortifying system stability and rectifying a multitude of underlying software defects. Comprising several hundred patches across diverse subsystems, this update prioritizes the enhancement of kernel security, driver interoperability, and overall robustness.

For sysadmins specifically,

Linux kernel 7.0 brings stable Rust driver support after six years of experimentation, autonomous XFS filesystem self-healing, a redesigned CPU scheduler with lazy preemption as default, io_uring BPF filtering, and post-quantum cryptography signing.

Each of these changes has security implications you need to understand before deciding what to enable on your fleet.

Ubuntu 26.04 LTS and Fedora 44 already ship with it, and RHEL 10, AlmaLinux 10, and Rocky 10 are tracking it.

In short: this kernel is coming to your servers whether you actively upgrade or not. Better to get ahead of it.

1. Post-Quantum Module Signing: The SHA-1 Retirement You Cannot Ignore

One of the most operationally significant security changes in Kernel 7.0 is a two-part shift in how kernel modules are cryptographically authenticated.

SHA-1 Is Finally Gone

The Linux 7.0 kernel has removed support for signing kernel modules using SHA-1 as it's no longer considered secure, but existing SHA-1 signed modules can still be loaded. The removal covers the module changes that include removing support for SHA-1 since it's no longer considered secure due to the possibility of hash collisions.

The kernel has defaulted to SHA-512 since v6.11

, so this removal is less of a breaking change and more of a formal closure. However, if you have any legacy out-of-tree modules or custom DKMS drivers still signed with SHA-1,

the removal of SHA-1 is part of a broader effort to harden Linux against modern threats. By adopting stronger cryptographic standards, Linux 7.0 ensures that only trusted, verified code can be loaded into the kernel, reducing the risk of rootkits, malware, and other forms of kernel-level attacks.

Action: Run grep CONFIG_MODULE_SIG_SHA1 /boot/config-$(uname -r) to confirm SHA-1 signing is not in use on your current builds. Audit any out-of-tree modules and re-sign with SHA-256 or SHA-512.

ML-DSA: Quantum-Resistant Module Signatures

This is the forward-looking half of the module-signing story.

A notable security-related change is the addition of ML-DSA post-quantum signatures for kernel module authentication.

Linux 7.0 adds ML-DSA signatures for kernel module verification. ML-DSA stands for Module-Lattice-Based Digital Signature Algorithm — a FIPS 204 standard approved by NIST. It was chosen precisely because lattice-based mathematics is a ferocious headache for both classical and quantum computers alike.

Three security levels are now available in the kernel: ML-DSA 44, 65, and 87.

Why does this matter today?

Although quantum computers aren't practically available today, the concept of "harvest now, decrypt later" means data encrypted today could be decrypted in the future when quantum computers are ready. Preparing for post-quantum cryptography at the kernel level is something organisations should start prioritising, especially those handling sensitive data such as financial information or personal data.

The kernel now supports verifying signatures made with ML-DSA, one of the post-quantum algorithms recently standardised by NIST. This is verify-only for now, but it is the right first step.

2. SELinux Gets BPF Token Access Control

Security-wise, Linux 7.0 updates SELinux with support for BPF token access control, adds support for verifying ML-DSA post-quantum signatures, and updates NETFILTER_PKT records to show both source and destination addresses.

The BPF system gains token-based authorisation for SELinux, enabling more granular access control for BPF programs.

This matters enormously for cloud-native shops.

BPF is the kernel technology behind tools like Cilium, Tetragon, and Falco, all commonly used in cloud-native security stacks.

Previously, granting a workload or container the ability to use BPF was an all-or-nothing proposition under SELinux — you either gave full BPF capabilities or none at all.

With token-based access control, SELinux policies can now delegate scoped BPF permissions to specific processes without opening the entire BPF subsystem. For SOC teams running detection-focused tooling inside containers, this is the granular control model you've been waiting for.

Action: If you use SELinux in enforcing mode alongside BPF-based observability tools, review and update your SELinux policies to take advantage of BPF token delegation rather than relying on blanket CAP_BPF grants.

3. io_uring BPF Filtering: Precision Control Over Async I/O

io_uring has been one of the most powerful — and most contentious — additions to the Linux kernel in recent years. Its performance is exceptional, but its attack surface has led many security-conscious administrators to disable it entirely in container environments.

Kernel 7.0 changes that calculus.

Linux 7.0 adds BPF filtering support to io_uring. This matters for containers, sandboxes, and environments with high security requirements. In the past, some administrators disabled io_uring entirely to reduce attack surface. With BPF filtering, they can now restrict allowed operations more precisely instead of choosing only between fully enabled and fully disabled.

Linux I/O expert Jens Axboe implemented support for loading BPF programs with io_uring for offering fine-grained filtering of SQE operations. This BPF filtering for io_uring can inspect request attributes and make dynamic filtering decisions compared to existing facilities for filtering. Filters can allow or deny requests, allow multiple filters to be stacked per opcode, and are done using classic BPF programs rather than eBPF programs to allow for container uses.

This does not make io_uring risks disappear automatically, but it gives system administrators and runtime frameworks a more controllable isolation tool.

Action: For containerised workloads that require io_uring for database or high-performance I/O, implement cBPF filters to restrict specific opcodes rather than reaching for the kill switch. Start by auditing which io_uring operations your workloads actually use, then build a filter that allows only those opcodes.

4. Landlock Sandbox Threading Fix: Silent Enforcement Gap Closed

Landlock sandboxing now works correctly in multithreaded programs. Landlock is the kernel's unprivileged sandboxing mechanism — it allows processes to restrict their own access to the filesystem and network without needing elevated privileges.

This sounds like a maintenance fix, but its security implications are significant.

Before Linux 7.0, there was a gap: programs that spawned threads before applying sandbox rules could end up with inconsistent enforcement across those threads. That gap is now closed. For services that use Landlock-based sandboxing, and for platforms that plan to, this removes a class of subtle enforcement failure that was hard to detect and easy to exploit.

Because Landlock is a stackable LSM, it makes it possible to create safe security sandboxes as new security layers in addition to the existing system-wide access controls. This kind of sandbox is expected to help mitigate the security impact of bugs or unexpected/malicious behaviours in user-space applications. Landlock empowers any process, including unprivileged ones, to securely restrict themselves.

Action: Verify Landlock is active on your systems with dmesg | grep landlock. If you're deploying multi-threaded services (Node.js servers, Java applications, Rust async runtimes), now is the time to integrate Landlock restrictions. With 7.0, you can trust those restrictions will be applied uniformly across all threads.

5. Rust in the Kernel: A Memory Safety Win for Security

While not a major release in terms of new features, despite the major version number change, Linux kernel 7.0 finally promotes Rust support to stable.

From a pure security standpoint, this matters enormously.

The immediate benefit for sysadmins is memory safety in these code paths: Rust eliminates the class of memory corruption bugs that cause kernel panics and have historically been the root cause of many CVEs.

The Rust kernel API in 7.0 covers PCI device enumeration, interrupt handling, DMA mapping, and platform device registration — the foundational building blocks for real hardware driver development. NVMe storage drivers and high-speed networking components written in Rust have moved from experimental to mainline stable.

This doesn't mean you need to do anything immediately — stable Rust support is an infrastructure improvement you benefit from passively. But if your team maintains out-of-tree kernel modules, Kernel 7.0 is the right moment to evaluate Rust as a language choice for future driver work.

6. KVM ERAPS Support and Virtualisation Hardening

For teams running virtualised environments on AMD hardware, Kernel 7.0 delivers a meaningful hardware-level security feature.

The Kernel-based Virtual Machine (KVM) can now virtualise and advertise support for ERAPS (Enhanced Return Address Predictor Security) on AMD CPUs (Zen5 or later) that support this feature.

ERAPS is a hardware-level mitigation designed to harden the return address predictor against speculative execution attacks — an entire class of vulnerability that has haunted modern processors since the Spectre and Meltdown disclosures. By virtualising and advertising this capability, KVM guests on Zen5 hardware can now take advantage of these protections at the hardware level rather than relying solely on software mitigations.

Action: If you're running KVM hypervisors on AMD EPYC Zen5 processors, confirm ERAPS is being exposed to guests by checking your VM configuration. Ensure guests are running Kernel 7.0 or a compatible kernel to actually consume the capability.

Practical Tips: Hardening Your System on Kernel 7.0

Here's a consolidated checklist of security actions sysadmins should take immediately after upgrading to Kernel 7.0:

These sysctls restrict eBPF to the CAP_BPF capability and enable JIT hardening techniques, such as constant blinding.

Consider assessing current cryptographic dependencies, developing migration timelines, and planning for continuous updates.

ML-DSA is in the kernel now — get ahead of the operational curve.
- Enable stack erasing:

Toggle stack erasing on with sudo sysctl kernel.stack_erasing=1. The performance cost is modest and the security payoff is large.

Mount /proc with the hidepid=2 option to prevent users other than root from viewing metadata of processes owned by other users, thereby improving confidentiality.

Conclusion: Don't Wait to Act on Kernel 7.0 Security

Linux Kernel 7.0 is not the revolution its version number might suggest — but it is a serious, well-executed tightening of the security architecture that underpins your entire infrastructure. The SHA-1 removal closes a long-standing gap in module trust chains. ML-DSA puts you on the right side of the post-quantum timeline. BPF filtering for io_uring restores a feature many teams had disabled entirely. Landlock threading fixes eliminate a subtle but exploitable enforcement gap. And Rust's promotion to stable begins reducing the memory-safety CVE surface for future drivers.

Linux 7.0 is a release that rewards teams who track upstream carefully.

Every one of these security features requires a deliberate decision to enable, configure, or audit — they don't magically activate themselves. The sysadmins who take the time to work through this checklist, update their SELinux policies, migrate away from SHA-1, and deploy io_uring filters will be operating systems that are measurably harder to compromise.

Ready to harden your Linux 7.0 deployment? Subscribe to our newsletter for step-by-step hardening walkthroughs, sysctl configuration templates, and security audit checklists delivered straight to your inbox. Share this post with your team, bookmark the checklist above, and start your Kernel 7.0 security review today — your future self (and your CISO) will thank you for it.