Linux users running a supported stable or long-term kernel should install their distribution’s latest kernel update. Linux 7.2.2 and seven other stable releases were published on 28 August 2026 to fix CVE-2026-80590, a networking flaw that can let an unprivileged local user crash an affected system under specific conditions.
What you need to know
- The fix is available in Linux 7.2.2, 7.1.12, 6.18.48, 6.12.107, 6.6.155, 6.1.186, 5.15.219 and 5.10.268.
- The reported impact is a kernel panic, which means denial of service—not confirmed remote code execution or data theft.
- Exploitation requires local access plus the ability to use a TUN/TAP or suitable AF_PACKET interface, so exposure varies by system configuration.
- Install the kernel supplied by your Linux distribution instead of downloading a kernel.org archive manually.
Which Linux kernel versions fix CVE-2026-80590?
The Linux stable team issued eight releases carrying the correction. The unusually broad set matters because the underlying code has existed for many years and is present across current stable and long-term-support branches.
| Kernel branch | Fixed release | Branch type |
|---|---|---|
| 7.2 | 7.2.2 | Stable |
| 7.1 | 7.1.12 | Stable |
| 6.18 | 6.18.48 | Long-term |
| 6.12 | 6.12.107 | Long-term |
| 6.6 | 6.6.155 | Long-term |
| 6.1 | 6.1.186 | Long-term |
| 5.15 | 5.15.219 | Long-term |
| 5.10 | 5.10.268 | Long-term |
The versions and release date are listed by the official Linux Kernel Archives. The stable updates contain the focused networking fix rather than a large collection of unrelated changes.
What is CVE-2026-80590?
CVE-2026-80590 affects the way the Linux networking stack reassembles fragmented IPv4 and IPv6 traffic. A packet supplied through TUN/TAP—or through AF_PACKET with a virtual-network header—can mark a fragment as a Generic Segmentation Offload (GSO) packet even though that state does not correctly describe the fragmented data.
During reassembly, the kernel previously retained the misleading GSO information. When the reconstructed packet later reached software segmentation, the kernel could encounter an internal consistency check and stop with a BUG condition. In practical terms, a successful trigger can panic or crash the kernel and interrupt the machine’s availability.
The upstream correction strips the GSO state from fragments before reassembly. That prevents later networking code from treating the reconstructed packet as if it had a valid offload layout.
Can the vulnerability be exploited remotely?
The available upstream description does not establish ordinary remote exploitation over the internet. The demonstrated path involves an unprivileged user writing crafted data to a TUN/TAP interface inside a user namespace. That means an attacker generally needs some level of local code execution and access to the relevant networking facilities first.
This distinction is important. Calling it a general remote takeover would overstate the evidence. The verified impact is local denial of service: an unprivileged user who can reach the necessary interface may be able to crash the host.
Multi-user systems, development workstations, CI workers, container hosts and virtualization servers deserve faster attention because they are more likely to run untrusted workloads or expose virtual networking features. A tightly controlled single-user desktop may face less practical risk, but applying the distribution update is still the sensible response.
Why are eight kernel versions being updated?
The vulnerable behavior dates back to Linux 2.6.27, according to the upstream security description. A problem that old can span numerous maintained branches. The stable team therefore applied the same focused correction to current stable kernels and multiple long-term branches still receiving official maintenance.
This does not mean every Linux installation is equally exposed. Distribution kernels often include backported patches and do not always share the exact version number shown on kernel.org. For example, a vendor may retain an older-looking base version while adding the CVE fix in a new package revision.
How to check your current Linux kernel
Run the following command:
uname -rThen check your distribution’s security tracker or package manager for its fixed kernel package. Comparing only the upstream version number can be misleading because Ubuntu, Debian, Fedora, RHEL-family distributions and cloud vendors backport security patches on different schedules.
How to install the security update
Use your distribution’s normal update mechanism. Do not replace a vendor kernel with a manually compiled upstream kernel unless you already maintain that configuration yourself.
| Distribution family | Update command |
|---|---|
| Ubuntu or Debian | sudo apt update && sudo apt full-upgrade |
| Fedora | sudo dnf upgrade --refresh |
| RHEL, Rocky or AlmaLinux | sudo dnf upgrade |
| Arch Linux | sudo pacman -Syu |
| openSUSE | sudo zypper update |
Reboot after installation so the system actually starts the patched kernel. A package can be installed on disk while the vulnerable kernel remains active in memory.
sudo reboot
uname -rOn production servers, follow your normal maintenance and rollback procedure. Confirm that storage, networking and any out-of-tree drivers work with the new kernel before completing a large fleet rollout.
Do containers need to be updated separately?
Containers share the host’s Linux kernel. Updating packages inside an application container does not replace the host kernel. Administrators should patch and reboot the worker node or container host, then verify that workloads have returned normally.
The same principle applies to many virtual private servers: the guest normally runs its own kernel and must receive the distribution update. Managed container platforms may patch nodes through the provider’s maintenance process, so consult the service notice rather than assuming the application image is enough.
Should all Linux users update immediately?
Yes, users should take the vendor-supported update when it becomes available. However, this is not evidence of an internet-wide emergency. There is currently no confirmed remote-code-execution claim in the upstream material, and the exploit path requires particular local networking capabilities.
The appropriate response is prompt routine patching: update, reboot, confirm the running version and monitor the relevant distribution advisory. Administrators of shared systems and hosts that allow untrusted containers or network namespaces should prioritize the change.
How this relates to Linux 7.2
Linux 7.2.2 follows shortly after the mainline Linux 7.2 release and supersedes 7.2.1 for users tracking the stable branch. Our Linux 7.2 release tracker covers the wider release, while our analysis of AI-assisted Linux kernel bug finding explains why maintainers may be reviewing a larger stream of potential defects.
If you administer Ubuntu or another server distribution, combine kernel updates with the practical controls in our Linux server hardening guide.
Sources
- Linux Kernel Archives: current stable and long-term releases
- CVE.org record for CVE-2026-80590
- Linux kernel documentation: segmentation offloads
Common questions
Does CVE-2026-80590 allow remote code execution?
No remote code execution has been established in the available upstream description. The documented consequence is a kernel panic triggered through specific local virtual-network interfaces.
Is installing the update enough without rebooting?
No. Linux continues running the currently loaded kernel until the system reboots. Install the vendor package, reboot and use uname -r to verify the active kernel.
Should I install Linux 7.2.2 manually on Ubuntu?
Normally, no. Install Ubuntu’s supported kernel package through APT and follow Canonical’s advisory. Distribution package versions can contain backported fixes even when their numbers differ from upstream releases.
Are containers protected after rebuilding their images?
Not by that action alone. Containers use the host kernel, so the host or cluster node must receive the patched kernel and be rebooted.
Comments