Eighteen-Year-Old Bug in Linux Networking Code Hands Attackers the Keys to the Machine
A flaw in Linux's SCTP networking that has been sitting in the code since 2008 lets a local user become root and break out of a container. Fixed kernels shipped on 3 August.
Key points
- A memory-handling bug in Linux's SCTP networking code, present since 2008, lets a local user gain full root control of the machine.
- Tencent researchers demonstrated using the flaw to escape a container and reach the underlying host.
- Fixed kernels 7.1.6, 6.18.42, 6.12.101 and 6.6.148 shipped on 3 August 2025.
- Any Linux system running an older kernel with SCTP reachable is exposed until patched.
- No public reports yet of criminal groups weaponising the bug in the wild.
A flaw that has been sitting quietly in the Linux kernel for seventeen years turns out to be enough to hand an attacker complete control of the machine.
The bug lives in the code that handles SCTP, a networking protocol used mostly in telecoms and some enterprise systems to move data between computers. It is a use-after-free flaw, which means the kernel keeps using a chunk of memory after it has already been freed up for other purposes. An attacker who can nudge the right data into that reused memory can rewrite what the kernel does next.
Researchers at Tencent, the Chinese technology giant, worked out how to turn that into root, the top level of access on a Linux machine. Root can read any file, install anything, and shut anything off.
What did the researchers actually do?
They used the bug to break out of a container and take over the host underneath. A container is a sealed box that runs an app in isolation from the rest of the server, and cloud providers rely on that isolation to keep one customer's code from touching another's. Escaping the container defeats that promise.
The finding, first reported by The Hacker News, matters most to anyone running shared Linux infrastructure: cloud hosts, telecoms kit, and multi-tenant servers where untrusted code is allowed to run.
How old is this bug?
It was introduced in 2008. That is not a typo. The faulty code has been shipping in mainstream Linux kernels for the best part of two decades, unnoticed by maintainers, distributors and the many companies that audit kernel networking code.
Eighteen-year-old flaws are rare but not unheard of. They tend to surface when a researcher looks at old code with fresh eyes, or when a new tool spots a pattern nobody was checking for before.
Is a fix available?
Yes. Stable Linux kernels 7.1.6, 6.18.42, 6.12.101 and 6.6.148 all shipped patches on 3 August 2025. Systems running any of those versions or newer are safe from this specific flaw.
| Kernel branch | Fixed version | Released |
|---|---|---|
| 7.1 | 7.1.6 | 3 Aug 2025 |
| 6.18 | 6.18.42 | 3 Aug 2025 |
| 6.12 | 6.12.101 | 3 Aug 2025 |
| 6.6 | 6.6.148 | 3 Aug 2025 |
Most major Linux distributions pull stable kernel fixes into their own updates within days. Server administrators should check what their machines are running and apply the vendor update as soon as it lands.
Who needs to worry about this?
Anyone with a Linux machine where SCTP is reachable and where untrusted users or code can run. That covers cloud providers, telecoms operators, and any shop running mixed workloads in containers on the same host. A desktop Linux user with no SCTP in play is not the target audience here.
There is no sign yet that criminals have picked up the bug. That gap between disclosure and exploitation tends to close quickly, especially for flaws that hand over root.
Ordinary customers of cloud services do not need to do anything. Your provider patches the host; you do not see the kernel. Watch for maintenance notices from your cloud vendor and expect brief reboots on affected fleets over the coming days.
