New security stuff in the Linux 6.17

Linux kernel v6.17 is on the horizon (expected release by the end of September 2025 – Canonical said to release 25.10 with the new kernel in early October), and it brings some interesting security-focused improvements. This release continues Linux’s trend of hardening the kernel against both hardware-level vulnerabilities and general attack vectors, while refining security subsystems for better performance and maintainability. Whether you’re on a SecOps or DevOps team, these updates aim to make Linux more secure out-of-the-box and easier to manage. Below we highlight the key security enhancements in Linux 6.17, with a brief overview of each change and why it matters.

Attack Vector Controls for CPU Mitigations

One of the headline features is the introduction of Attack Vector Controls (AVC) – a new framework that simplifies how administrators manage CPU vulnerability mitigations. Instead of toggling dozens of individual mitigations for speculative execution bugs (Spectre, Meltdown variants, etc.), you can now manage them in groups based on attack scope. The kernel classifies mitigations into five categories: user-to-kernel, user-to-user, guest-to-host, guest-to-guest, and cross-thread. With a single mitigations= boot parameter, you can opt out of entire classes of attacks (e.g. disable all mitigations for guest-to-guest if you don’t run untrusted VMs) to reclaim performance. 

# Example: disable user-to-kernel attack mitigations, keep others at auto defaults GRUB_CMDLINE_LINUX="... mitigations=auto,no_user_kernel ..."

By focusing protections only where relevant, Attack Vector Controls help keep systems safe without the performance cost of unrelated mitigations.
Sources: Phoronix – Linux 6.17 Attack Vector Controls, Linux kernel docs on mitigations

Refined Spectre & SRSO Mitigations

Linux 6.17 also brings some housekeeping improvements to existing x86 CPU mitigations. Notably, the Retbleed mitigation code has been untangled from Intel’s “Interrupts Tracing Stall” (ITS) mechanism so that ITS stuffing can be enabled or disabled independently. This gives administrators finer control – for example, enabling one mitigation without needlessly incurring the cost of the other. Additionally, the kernel’s handling of Speculative Return Stack Overflow (SRSO) vulnerabilities was streamlined. SRSO is now tagged under the Attack Vector Controls system so the kernel can automatically choose the appropriate SRSO defense only when those attack vectors matter. These tweaks ensure that Spectre-class mitigations are more precise, avoiding unnecessary performance hits.

How to control SRSO mitigations:

# Enforce IBPB on all privilege crossings GRUB_CMDLINE_LINUX="... spec_rstack_overflow=ibpb ..."

After boot, check the active mitigation via sysfs:

$ cat /sys/devices/system/cpu/vulnerabilities/spec_rstack_overflow Mitigation: Safe RET

This file will show “Mitigation: Safe RET” by default, or “IBPB”/“IBPB on VMEXIT” if those modes are active.

Sources: Phoronix – Linux 6.17 Mitigations Round-Up

Rust Code CPU Mitigation Support

Linux’s budding Rust infrastructure is also getting security upgrades. In 6.17, Rust components within the kernel properly integrate with CPU vulnerability mitigations that were historically implemented for C code. The Rust-for-Linux team introduced changes to pass the appropriate compiler flags so that defenses like Retpoline, Rethunk, and Straight-Line Speculation (SLS) protections are enabled when building Rust code in the kernel. In short, any Rust-written drivers or modules will now be hardened against speculative execution attacks just like their C counterparts. Linux won’t move to Rust in the near future, but the continuous investment in this direction is promising that in a few years, we will have a considerable amount of Rust code in the kernel, which will enhance memory stability and security!

Enable Rust support in the kernel build:

CONFIG_RUST=y # Enable Rust language support in the kernel CONFIG_RUST_OVERFLOW_CHECKS=y # Panic on integer overflow in Rust code

Enabling these ensures Rust code uses the same mitigations as C code.

Source: Phoronix – Rust Linux Kernel Code Prepares For CPU Mitigations Handling

SELinux Auditing & Performance Improvements

Security-Enhanced Linux (SELinux) sees some notable enhancements in this release:

• neveraudit Flag – A new per-domain flag called neveraudit completely suppresses auditing for that domain. This is a stronger version of dontaudit and can dramatically improve performance for unconfined or permissive domains.
• Deprecated Sysfs Warning – Accesses to the old /sys/fs/selinux/user file now incur a 5-second delay and warning, helping identify lingering legacy usage.
• Audit Fixes – A regression that failed to log some failed kernel module load events has been fixed.

Source: Paul Moore – Linux 6.17 SELinux Merge Notes

Linux Lockdown LSM Maintained Again

The kernel’s Lockdown security module – which can enforce an integrity/security lockdown on the kernel even against the root user – gets a new lease on life in 6.17. The Lockdown LSM had been unmaintained since Linux 5.4; in Linux 6.17, Nicolas Bouchinet and Xiu Jianfeng have volunteered as maintainers. Active maintainers mean the Lockdown module’s bugs will be addressed and its features kept up-to-date.

Enable it in confidentiality mode at boot:

# Enable Lockdown LSM at boot in confidentiality mode GRUB_CMDLINE_LINUX="... lockdown=confidentiality ..."

Or, at runtime, switch Lockdown on:

echo "integrity" | sudo tee /sys/kernel/security/lockdown

AppArmor Gains AF_UNIX Socket Mediation

Linux 6.17 extends the reach of AppArmor by adding support for mediating AF_UNIX domain sockets. This means AppArmor security profiles can now restrict or allow Unix socket connections with fine granularity – including based on socket type, address, and labels. This feature was long out-of-tree but is now mainlined, closing a gap in process isolation.

Example allowing /foo to connect to an abstract socket “@bar” owned by /bar:

# In profile "/foo": allow connecting to socket "@bar" owned by profile "/bar" unix (connect, send, receive) type=stream peer=(label=/bar, addr="@bar"),

And in /bar’s profile:

# In profile "/bar": allow accepting connections on "@bar" from peer "/foo" unix (accept, receive) addr="@bar" peer=(label=/foo),

Kernel Stack Erasing for Better Memory Safety

A quieter but important hardening in Linux 6.17 is the improvement in kernel stack memory clearing. The kernel can now take advantage of Clang 15+ compiler features to automatically wipe sensitive data from the stack after use, reducing the chances of info leaks from uninitialized stack memory. This change raises the baseline security of Linux by reducing data lifetime in memory.

Check status:

$ cat /proc/sys/kernel/stack_erasing 1

A value of “1” means stack wiping is enabled. Toggle with:

sudo sysctl kernel.stack_erasing=0 # disable sudo sysctl kernel.stack_erasing=1 # enable

The performance cost is modest and the security payoff is large.

Source: Phoronix – Linux 6.17 Clang Stack Erasing

Other Noteworthy Changes

In addition to the highlights above, Linux 6.17 includes numerous fixes and minor enhancements across its security landscape. The Integrity subsystem, Linux Security Modules generally, and Landlock sandboxing all saw routine updates. It’s also worth noting the responsiveness of the kernel team to emerging threats: during the 6.17 cycle, a new CPU vulnerability dubbed “VMSCAPE” (which could allow a malicious VM to escape and attack host processes) was disclosed – and Linux was patched to mitigate it using Spectre-v2 techniques (IBPB flushes) almost immediately. By the time 6.17 ships, it will include that mitigation, demonstrating how quickly the kernel can adapt to protect users even from freshly revealed attacks.
Sources: Phoronix – Linux 6.17 Mitigations, VMSCAPE disclosure write-up

The security enhancements in Linux 6.17 showcase the kernel community’s commitment to both proactive hardening and practical usability:

• Mitigations Made Manageable – CPU side-channel defenses are crucial, but they often carry performance costs. Features like Attack Vector Controls give admins a simple toolkit to dial in exactly the protections they need for their threat model – no more, no less.
• Secure-by-Default, with Flexibility – By grouping mitigations and refining Spectre-type fixes, Linux 6.17 helps systems stay secure against the latest CPU vulnerabilities by default, while allowing knowledgeable users to selectively disable unneeded safeguards to regain efficiency.
• Evolving Security Ecosystem – SELinux’s new neveraudit flag benefits performance in common “permissive” deployments, AppArmor’s socket mediation closes a longtime gap in container/workload confinement, and Lockdown is maintained again.
• Preparing for the Future – Ensuring Rust code respects CPU mitigations signals that new kernel components will be as hardened as the old ones. Likewise, improvements like Clang-assisted stack erasing show an investment in toolchain features to eliminate entire classes of vulnerabilities at compile-time.

In summary, Linux 6.17’s security features span from low-level silicon defenses to higher-level policy controls. This release makes Linux more robust against hardware attacks, more efficient in enforcement, and easier to adapt to your environment’s needs. All these changes continue to advance Linux’s security without requiring kernel insiders to understand – they’ll mostly “just work” in the background, but knowing about them lets SecOps and DevOps teams take full advantage. As the kernel keeps iterating, staying aware of these updates helps you keep your systems locked down and running smoothly on the latest Linux.

Linux 6.17 underscores a broader trend in infrastructure security: baking in protections and performance optimizations at the core, so that end-users and administrators get safer systems by default. From smarter CPU mitigation management to incremental improvements in access controls, this kernel release is a solid step forward for security-conscious Linux users. Keep an eye out for 6.17’s final release and consider testing these features in your environment – you may find meaningful gains in both security posture and system performance. Happy (and safe) upgrading!

Sources: The information and quotes in this article are drawn from the Linux 6.17 kernel documentation and merge announcements, including Michael Larabel’s coverage on Phoronix and insights from kernel developers (e.g. Paul Moore’s SELinux update notes). Relevant sources are cited inline for verification.