The SCTP Use-After-Free You Probably Don't Run — But Might Load

A use-after-free landed on oss-security this week as CVE-2026-64564, in the Linux kernel's SCTP code — specifically the ASCONF transport handling. The advisory and a follow-up describe it as local privilege escalation and container escape. Those two phrases are what make people forward a CVE to their whole team on a Friday, so it's worth stopping to ask what it actually means for the machines this blog is about: Postfix relays, Dovecot backends, Zimbra boxes, iRedMail stacks.

Let me be honest about my sources first. The oss-security posts decline AI crawlers, so I have their headlines and nothing more. The exact affected range, the fixed versions, and the CVSS number live in the advisory text I can't quote here — go read it yourself before you cite figures. LWN also noted six stable kernels with a security fix the same day; I can't confirm from the headline that they're the SCTP fix specifically, so don't assume it.

SCTP is not in your mail path

Here's the part the headline won't tell you. SCTP — the Stream Control Transmission Protocol — is a telecom-world transport. It carries SIGTRAN, Diameter, some WebRTC data channels. Postfix speaks TCP. Dovecot speaks TCP. Your LDAP, your milters, your submission and IMAPS listeners: TCP, all of it. If you have never deliberately configured SCTP, no part of your mail server uses it.

So on the face of it, this is a "if you run X you can ignore this" story. The catch is the word loadable.

The real question: can an unprivileged user pull the module in

The classic shape of these obscure-protocol kernel bugs — DCCP, n_hdlc, and friends over the years — is that the vulnerable code isn't running until someone asks for it, and on a stock distro anyone can ask. A local user opening an SCTP socket can trigger kernel module autoloading and bring sctp in on demand. That's the pivot from "we don't use SCTP" to "a local account, or a process inside a container, can reach code we never intended to expose."

That reframes both your exposure and your mitigation:

• Exposure. The threat is local. It's the shell user on a shared box, the web app that got popped, the workload in a container that shouldn't be trusting the host kernel. If your mail stack runs in containers sharing the host kernel — and most do — a container escape via a host kernel UAF is exactly the boundary you were relying on.
• Mitigation, in order. Patch the kernel; that's the real fix. Until you've rebooted onto a fixed build, the pragmatic move on a machine that genuinely never uses SCTP is to stop the module loading at all — check whether sctp is currently in your loaded-module list, and if it isn't, use your distro's module-blacklist mechanism to keep a socket call from autoloading it. I'm deliberately not pasting an exact incantation because the advisory I'd copy it from isn't readable to me; look up your distro's blacklist syntax and confirm it on a test box first. Blacklisting is a stopgap, not a substitute for the patch.

Where it sits in a noisy week

This didn't arrive alone. The same day brought Zapscape, a KVM guest-to-host escape (CVE-2026-64561); the Interrupt Injection / TONTOU Spectre-v2 bypass that Phoronix and BleepingComputer also covered; and a kernel lockdown regression leaving legacy I/O handlers open. The through-line is trust boundaries — guest/host, container/host, user/kernel — quietly not holding. SCTP is the least glamorous of them and, for most mail operators, the easiest to neutralise: patch, and if you don't need the protocol, don't let it load.

Sources

• oss-security: CVE-2026-64564 (original post)
• oss-security: Re: CVE-2026-64564
• oss-security: Zapscape (CVE-2026-64561)
• LWN: Six stable kernels with a security fix
• The Hacker News: New Zapscape KVM Flaw
• The Hacker News: New Interrupt Injection Attack
• Phoronix: Linux Patched For Safe RET Interrupt Vulnerability
• Phoronix: Legacy I/O & Memory Handlers Open In Kernel Lockdown Mode
• BleepingComputer: New TONTOU CPU attack