Linux Kernel SCTP Fix Lands in All Stable Branches

A use-after-free bug in the Linux kernel's SCTP implementation, dating back to behavior introduced in Linux 2.6.25 roughly eighteen years ago, has been fixed and backported across every supported stable branch. Tracked as CVE-2026-64564 and named SCTPhantom by the Tencent Zhuque Lab researchers who found it, the flaw went from private disclosure on July 12 to a formal CVE announcement on August 4 to patches in 6.6.148, 6.12.101, 6.18.42, and 7.1.6. That timeline is the story worth telling.

• CVE-2026-64564 is a use-after-free in SCTP Dynamic Address Reconfiguration handling, with roots in Linux 2.6.25
• Private disclosure began July 12, 2026; the Linux kernel CVE team announced formally on August 4
• Fixes are backported to stable branches 6.6.148, 6.12.101, 6.18.42, and 7.1.6
• Distribution updates are shipping, including a Debian 13 kernel security update covering the issue

What the Bug Actually Was

The technical shape is instructive. SCTP supports dynamic address reconfiguration, letting an association add or remove transport addresses while it is running. The flaw comes from a mismatch between the IPv4 packet source address used for validation and the address parameter used to select which transport to act on. Craft an ordered sequence of reconfiguration messages exploiting that gap, and you can remove a live transport object while the association's primary path and active path pointers still reference it.

What remains is a stale pointer to freed memory — the classic use-after-free setup. Researchers developed it into a demonstrated local privilege escalation across multiple distributions and kernel versions using controlled heap reallocation, first obtaining a kernel memory disclosure and then manipulating kernel object relationships from there. It requires local access to exploit, but from unprivileged local access it reaches root, and from inside a container it reaches the host.

Why Did It Take Eighteen Years to Find?

This is the question worth sitting with, and the answer is not negligence. SCTP is not a heavily trafficked protocol on most systems. It sees real use in telecom signalling and some clustering setups, but the overwhelming majority of Linux machines never process an SCTP packet in their operational lifetime. Code paths that rarely execute attract proportionally less scrutiny — fewer eyes, less fuzzing coverage, fewer accidental discoveries.

The address reconfiguration path is a subset of a subset: an uncommon feature within an uncommon protocol. That is exactly the profile of code where long-lived bugs hide, and it is a useful reminder for anyone maintaining a large codebase. Your oldest untested branch is your most likely surprise.

What Should Administrators Do This Week?

The practical guidance is short:

• Apply your distribution's kernel update. Debian 13 has shipped one covering this, and other distributions are following the same stable backports
• If you run containers on shared hosts, treat this as higher priority — container escape to host root is the impactful path here
• If SCTP is not needed on a given system, verify whether the module is loaded and consider blacklisting it. Reducing loaded surface area is cheap insurance for a protocol you do not use
• Confirm your running kernel version after reboot rather than assuming the package update took effect

The Process Worked, and That Is the Point

It is easy to read a headline about an eighteen-year-old kernel flaw as bad news. Look at the timeline instead. Private report on July 12. Coordinated disclosure. Formal CVE on August 4. Patches backported to four stable branches and flowing into distribution updates within days. Detailed technical writeups published so defenders can understand what they are patching.

That is coordinated disclosure functioning as designed, and it is the same pattern our AI security coverage has tracked across recent research — including the AI-assisted HTTP desync work published this month, where findings went to vendors before they went public. The bugs will always be there; what determines the outcome is how quickly the ecosystem can move from discovery to deployed fix. Three weeks, four branches, no observed exploitation ahead of the patch. That is a good week for the defenders.

Sources: The Hacker News — August 7, 2026; Tencent Zhuque Lab — August 6, 2026; oss-security mailing list — August 6, 2026; 9to5Linux — August 2026.