What's new in Linux kernel 7.1 for servers

What is new in Linux kernel 7.1

Linux kernel 7.1 was released on 14 June 2026, nine weeks after 7.0. For a VPS (virtual private server) tenant the changes that matter sit in four areas: storage and filesystems, networking, memory management, and process and container control. The rest of the release is mostly desktop and graphics work that a headless server never loads.

There is a second answer you need first. 7.1 is almost certainly not running on your server, and it will not be for a long time. kernel.org does not list 7.1 as a longterm release. As of 11 August 2026 the longterm lines are 6.18, 6.12, 6.6, 6.1, 5.15 and 5.10, and every mainstream server distribution builds on one of those or on a line it maintains itself. "New in the kernel" and "new on your server" are years apart, so this guide covers both halves.

Which kernel is your VPS running right now

uname -r
uname -srm
systemd-detect-virt

uname -r prints the running kernel release. On Ubuntu 24.04 it looks like 6.8.0-79-generic. The part before the first dash is the upstream line. Everything after it is your distribution's own build number, and it does not track upstream at all. Canonical's 6.8.0-79 carries thousands of fixes backported from later kernels, so it is not the code Linus tagged as 6.8 in March 2024. This is why "my kernel is old" says less than it sounds like it does. The features are old. The security fixes usually are not.

systemd-detect-virt tells you whether you can change the kernel at all. It prints kvm on a full virtual machine, where you boot your own kernel image and an upgrade is a real upgrade. It prints lxc or openvz on container virtualisation, where the host kernel is shared. On a container plan uname -r shows the provider's kernel, installing a kernel package changes nothing you can boot, and no feature in this release is available to you until the provider reboots the host onto a newer kernel. Run this check before you plan any kernel work.

[
  {
    "distro": "Ubuntu 26.04 LTS (7.0)",
    "releases_behind_7_1": 1,
    "notes": "GA kernel, shipped with the April 2026 release"
  },
  {
    "distro": "Ubuntu 24.04 LTS, HWE (6.17)",
    "releases_behind_7_1": 4,
    "notes": "6.17 came with 24.04.4; 7.0 is rolling out ahead of 24.04.5 on 27 August 2026"
  },
  {
    "distro": "Debian 13 trixie (6.12)",
    "releases_behind_7_1": 9,
    "notes": "upstream longterm line, kernel.org projected EOL December 2028"
  },
  {
    "distro": "RHEL 10 and its rebuilds (6.12)",
    "releases_behind_7_1": 9,
    "notes": "Red Hat backports fixes into its own frozen 6.12 stream"
  },
  {
    "distro": "Ubuntu 24.04 LTS, GA (6.8)",
    "releases_behind_7_1": 13,
    "notes": "the default unless you install the HWE stack"
  },
  {
    "distro": "Ubuntu 22.04 LTS, GA (5.15)",
    "releases_behind_7_1": 26,
    "notes": "upstream longterm line, kernel.org projected EOL December 2026"
  }
]

That is 6 platforms, and not one of them boots 7.1. The newest is Ubuntu 26.04 LTS (7.0), which is 1 upstream release behind. The oldest still in support is 26 releases behind. Ubuntu 24.04's default GA kernel sits 13 releases back, and Debian 13 and RHEL 10 sit 9 back on the 6.12 longterm line. Counting releases is a rough measure, because it ignores everything the distributions backport, but it shows the shape of the gap. If you are weighing which of these to run, the LTS against interim release trade-off on a server is the decision underneath these numbers.

Storage and filesystems in 7.1

7.1 adds the ability to generate and verify T10 PI (protection information) inside the filesystem rather than only in the block layer, along with flexible T10 alignment support. T10 PI is extra bytes attached to each block, holding a checksum plus a tag that identifies which block the data belongs to, so a misdirected or torn write is caught instead of being handed back as good data. The catch for a VPS tenant is the hardware. Integrity metadata has to be exposed by the device, and a virtual disk normally does not expose it.

ls /sys/block/vda/integrity/

On most VPS disks that returns No such file or directory, because the block layer only creates the integrity directory when the device registers integrity support. That error is the normal answer here, not a fault. If you want to know what your disk really is before you read any further into storage features, checking whether the VPS disk is actually NVMe comes first, and the gap between NVMe and a SATA SSD on a VPS explains why the answer changes your numbers.

Btrfs gets fixes for copy-on-write amplification under memory pressure, plus a change that speeds up clearing the first extent in a tracked range, reported at 10% more throughput on the sample workload the merge names. Its shutdown operation is no longer marked experimental. XFS improves zero range flushing and lookup through iomap, and adds a write pointer to real-time group geometry, which is groundwork for zoned devices. NTFS is a complete rewrite in this release, with full write support and an iomap conversion, which matters if you ever mount a disk image from a Windows machine on your server.

Smaller storage items worth knowing: ublk, the user-space block driver, gained zero-copy I/O; io_uring gained SCSI passthrough commands; SED-OPAL self-encrypting drive support gained the STACK_RESET command and extended single user mode; there is a new fs-dax character driver for direct-access devices; and the VFS widened inode->i_ino from unsigned long to u64, which removes an inode number ceiling on 32-bit builds. On the network filesystem side, the in-kernel NFS server can now sign its file handles through a sign_fh mount option, and the CIFS client learned O_TMPFILE.

Networking: queue leasing, and what it gives a container

The headline networking change is hardware queue leasing. A virtual netdev can now lease a queue that is bound to a real queue on a physical netdev, and act as a proxy for it. The point of this is containers. Until now, a container that wanted AF_XDP (address family express data path, the socket type that hands raw packets to user space without copying them up through the network stack) had to be given something close to the whole device. With a leased queue it gets one hardware queue, runs AF_XDP and memory providers at native speed, and the host keeps the rest of the NIC. This lands next to AF_XDP support in io_uring's zero-copy path.

On the ordinary side, sockets in sockfs now accept user.* extended attributes. A path-based AF_UNIX socket already inherited xattr support from the filesystem underneath it, but a socket living only in sockfs had none. Now a process can label a socket, and an eBPF program can filter on that label.

Two removals. UDP-Lite is gone, having found no users. IPv6 can no longer be built as a loadable module: if you want IPv6, it is compiled in. The second one is invisible on any distribution kernel, because the common server distributions already build IPv6 in.

Memory management: the swap table is finished

The swap rework reaches its third phase, and this phase removes the static swap map. The swap count now lives in the swap table directly. The reported saving is about 30% of the static swap metadata, which is memory the kernel holds in proportion to the size of your swap device whether or not anything is swapped. In absolute terms that is small on a small swap file, and it grows with the swap you configure.

MGLRU (multi-generational least recently used, the newer page reclaim algorithm) can now check the young flag on pages in batches instead of one page at a time. The figure published with the change is more than 60% improvement on an Arm64 32-core server. Batching pays off most where the per-page cost is highest, which is why that number came off a large Arm machine. If you run an Arm VPS rather than an x86 one, this is the 7.1 change most likely to show up in your own measurements, though not at that scale on two or four cores.

Also here: transfers out of dying memory cgroups are gone, khugepaged scans with less CPU, and the maple tree got a large refactor around its big node handling. None of these are things you configure. They are things you notice as slightly less system time.

Schedulers: sched_ext sub-schedulers, and FRED on by default

sched_ext, the extensible scheduler class that lets you write a CPU scheduler as a BPF program and load it at runtime, arrived in 6.12. 7.1 adds the core structure for sub-schedulers, so that a control group can eventually run under its own scheduler. Read that sentence carefully. The implementation is not finished in 7.1, and the enqueue path in particular is missing, so this is groundwork for a later release rather than something you can switch on today.

Intel FRED (flexible return and event delivery) is now enabled by default on hardware that supports it. FRED replaces the legacy x86 event delivery path with a cleaner one, and it has been in the kernel since 6.9 behind the fred=on boot argument. Flipping it to on by default is a statement that shipping hardware has been tested enough. The measurements published so far, in the range of 4% to 7% on I/O heavy workloads, come from Phoronix testing on client silicon, so do not budget for that on a server until you have measured your own workload.

Proxy execution gained donor migration for boosting a remote lock owner, EEVDF got fixes around negative lag, and the high-resolution timer core was substantially rewritten. These are latency-quality changes that no configuration file exposes.

New process and container controls in clone3()

Three flags were added to clone3(), and each one closes a gap that supervisors have worked around by hand for years. CLONE_AUTOREAP makes the child reap itself on exit, so it never becomes a zombie waiting for a parent that may never call wait(). CLONE_NNP sets no_new_privs on the child at creation time, which closes the window between the clone and the child setting the flag for itself. CLONE_PIDFD_AUTOKILL ties the child's lifetime to the pidfd returned to the parent: close the pidfd and the child is killed, so a supervisor that dies cannot leave orphans running.

Mount namespaces got the same treatment. CLONE_EMPTY_MNTNS for clone3() and UNSHARE_EMPTY_MNTNS for unshare() create a mount namespace with nothing in it, instead of the usual full copy of the parent's mounts that a runtime then has to unmount. FSMOUNT_NAMESPACE lets fsmount() place a filesystem straight into a new namespace. Container runtimes have been assembling this by hand for a decade, so doing it in one call means a runtime no longer starts from a namespace full of the host's mounts.

On the virtualisation side, guest_memfd now supports userfaultfd, so a hypervisor can handle guest page faults from user space. Protected KVM on Arm gained anonymous memory support, which the merge itself describes as not production ready.

When does kernel 7.1 reach your server

Fedora already has it. The Fedora 44 update repository moved onto the 7.1 series during July and August 2026, because Fedora rebases its kernel onto new stable lines within a release. Arch and openSUSE Tumbleweed have it for the same reason. Those are machines to test on, not machines to run your services on.

Everything else waits, and the waiting is by design. Debian 13 shipped with 6.12 and stays on 6.12 for the life of the release, with fixes backported into it. RHEL 10 shipped 6.12.0 and does the same. Ubuntu 26.04 LTS shipped 7.0 in April 2026. Ubuntu 24.04 LTS has a hardware enablement stack, which pulls a newer kernel from later Ubuntu releases into the LTS, and that stack is on 6.17 as of the 24.04.4 point release, scheduled to move to 7.0 with 24.04.5 on 27 August 2026. A point release is not a new version of Ubuntu, only the same 24.04 with every update since rolled into fresh install media, so what 24.04.5 changes on a server you already patch is the HWE kernel line and very little else.

Here is the part people get wrong. An HWE stack jumps to whatever kernel the newest interim release carries, so it can skip an upstream line completely. 7.0 is in an Ubuntu LTS. 7.1 may never be the base of one, because the interim release after it will carry a later line. What reaches your LTS from 7.1 is the fixes, backported into whichever line you are on. The features mostly stay behind.

If you do want a newer kernel on a stable server, the supported routes are short.

# Ubuntu 24.04 LTS: install the hardware enablement stack
sudo apt update
sudo apt install --install-recommends linux-generic-hwe-24.04
sudo reboot

# Debian 13, with trixie-backports enabled in your apt sources
apt-cache policy linux-image-amd64
sudo apt install -t trixie-backports linux-image-amd64
sudo reboot

After the reboot, check what you actually booted:

uname -r
dpkg -l 'linux-image-*' | grep ^ii
ls /var/run/reboot-required

uname -r should now show the new line, and dpkg -l shows every kernel image still installed. If uname -r shows the old version while dpkg -l lists the new one, the package installed but the bootloader default did not move: look at the GRUB menu entries. /var/run/reboot-required existing means a package upgraded the kernel and nothing has rebooted since, which is the most common reason a patched server is still executing the vulnerable code.

Should you chase 7.1 on a production VPS

No, and the reason is not caution for its own sake. A distribution kernel is a support contract. Canonical, Red Hat, SUSE and Debian each backport security fixes into their frozen line and test them against the userspace they ship alongside it. A mainline kernel from a third-party archive or a hand build gives you the features and takes away that work, because nobody is backporting fixes into your build. You become the maintainer of a kernel.

The exceptions are real but narrow: hardware the older kernel cannot drive, or a performance change you have measured on your own workload and want badly enough to own the consequences. On a VPS the first almost never applies, because the hardware you see is virtual. For everything else, keep the distribution kernel current and reboot when it asks. If a distribution upgrade is already on your list, moving from Ubuntu 24.04 to 26.04 takes you from 6.8 to 7.0 in one step, which is a larger jump than any single kernel package will hand you.

FAQ

How do I check which Linux kernel my VPS is running?

Run uname -r. It prints something like 6.8.0-79-generic. The number before the first dash is the upstream line your distribution builds on, and everything after it is the distribution's own build number, which carries backported fixes. Then run systemd-detect-virt. If it prints lxc or openvz, you are on container virtualisation, you share the host's kernel, and you cannot change it. If it prints kvm, you boot your own kernel image and upgrades are yours to make.

Is Linux 7.1 a longterm support kernel?

No. As of 11 August 2026 the longterm lines listed on kernel.org are 6.18, 6.12, 6.6, 6.1, 5.15 and 5.10, and 7.1 is not among them. It is a normal stable release, and its stable line is dropped soon after the next mainline release appears. If you want a kernel with years of fixes behind it and years of fixes ahead, that is what your distribution's kernel already is.

When will Ubuntu or Debian ship kernel 7.1?

Probably never as a default. Debian 13 stays on 6.12 for the life of the release, and RHEL 10 stays on 6.12.0. Ubuntu 26.04 LTS shipped 7.0, and an Ubuntu hardware enablement stack jumps to whatever kernel the newest interim release carries, so it can skip an upstream line entirely. Ubuntu 24.04 LTS is scheduled to move its HWE kernel to 7.0 with the 24.04.5 point release on 27 August 2026. The fixes from 7.1 will reach you as backports into an older line. The features usually will not.

What in Linux 7.1 actually matters on a virtual private server?

Four items. Hardware queue leasing lets a container use one real NIC queue for AF_XDP at native speed. The third phase of the swap rework removes the static swap map and cuts the metadata the kernel holds for your swap device by a reported 30%. MGLRU can check page young flags in batches, with the largest published gain on a many-core Arm server. And clone3() gained CLONE_AUTOREAP, CLONE_NNP and CLONE_PIDFD_AUTOKILL, which make supervising child processes safer. Filesystem-level T10 protection information landed too, but a virtual disk rarely exposes the integrity metadata it needs.

Will upgrading my kernel break my VPS?

The common failures happen at boot. A full /boot makes update-initramfs fail with No space left on device during install, leaving the package half configured: clear old kernels with sudo apt autoremove --purge, then reinstall. Out-of-tree modules built against the old kernel stop loading, so anything managed by DKMS has to rebuild, and a failed rebuild is silent until the module is missing at runtime. And if uname -r still reports the old version after a reboot while dpkg -l lists the new image, nothing broke in the install: the bootloader default did not move.