Oct 23, 2026

Linux Kernel SCTP Flaw CVE-2026-64564 Scores 9.8: Your Server Does Not Use SCTP, but Any User Can Load It

7 min readApply in about 20 minAdvanced

A Linux kernel flaw in the SCTP protocol code has a CVSS score of 9.8, and Ubuntu says the fix is in newer kernels. Most servers never use SCTP, so the usual reaction is “not my problem”. I checked my own Ubuntu server and found something that should change that reaction: the SCTP module was not loaded, yet an ordinary user with no special rights switched it on with one line of Python.

This post gives you the facts about CVE-2026-64564, the three-line check I ran with real output, and the one-line fix that Ubuntu itself recommends. It also shows where my own fix is still incomplete, because the module would not unload.

Linux kernel SCTP flaw rated 9.8: the module is not loaded until any user opens one socket

Quick guide

  1. Check whether SCTP is loaded with lsmod and whether it is available with the kernel config file.
  2. Test whether an ordinary user can load it by opening an SCTP socket. If it works, “not loaded” is not protection.
  3. Block the module with a modprobe rule if you do not need SCTP.
  4. Update the kernel to the fixed version for your flavor, then reboot into it.

What the flaw is

Ubuntu’s security tracker describes CVE-2026-64564 as a flaw in how the kernel handles an SCTP ASCONF request. When a delete-address request is processed, the association’s own transport can be freed too early, which leads to a use-after-free and memory corruption. The tracker rates it Critical with a CVSS score of 9.8. It was published on August 4, 2026, and the page was last updated on October 22, 2026.

SCTP (Stream Control Transmission Protocol) is a transport protocol like TCP and UDP. It is used mostly by telecom signalling and a few clustering products. A normal web, mail or file server does not use it.

Which kernels are fixed

This is what the Ubuntu tracker page showed when I read it today for Ubuntu 24.04 (noble). Check the page again before you act, because these rows change.

Kernel packageStatus on the tracker
linux (generic)Fixed in 6.8.0-147.147
linux-hwe-7.0Fixed in 7.0.0-38.38~24.04.4
linux-oracleFixed in 6.8.0-1064.67
linux-oracle-6.17Ignored, end of life (it was marked “needed”)

That last row matters to me. My server runs 6.17.0-1020-oracle. If the tracker row is right, that kernel line is not getting a fix, so for this server the realistic options are to move to a supported kernel or to block the module. I am not changing my kernel for this post, so I took the second option.

Step 1: is SCTP loaded, and is it even built

Run these as a normal user. The kernel config file tells you whether SCTP exists as a loadable module (=m), is built in (=y), or is absent.

uname -r
lsmod | grep -i sctp || echo "(sctp not loaded)"
grep CONFIG_IP_SCTP /boot/config-$(uname -r)

Step 2: can an ordinary user load it anyway

This is the check most posts skip. A module that is not loaded can still be loaded on demand. When a program asks the kernel for a protocol it does not have, the kernel runs modprobe for it. Protocol number 132 is SCTP. Save this as a small script and run it as a normal user, never as root:

import socket
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM, 132)
print("sctp socket created")
Terminal showing sctp not loaded, then an unprivileged user creating an SCTP socket, then the sctp module loaded
Real output from my Ubuntu 24.04 server. Callout 1 is the module before the test, callout 2 is the socket created by user id 1001, callout 3 is the module now loaded.

On my server the module was not loaded, the user ID was 1001 (not root), and the socket was created without any error. Right after that, lsmod showed sctp loaded. So “not loaded” meant “not loaded yet”.

I want to be precise about what this proves. It proves that an unprivileged user can bring the SCTP code into the running kernel. It does not prove the flaw is reachable by that user, because the bug is in ASCONF processing and I did not test it and will not. Treat the SCTP code as attack surface you can remove.

Step 3: block the module

If nothing on the machine needs SCTP, Ubuntu’s own advisory recommends this rule:

echo "install sctp /bin/false" | sudo tee /etc/modprobe.d/disable-sctp.conf
sudo modprobe -c | grep "install sctp"
sudo modprobe -r sctp

The first line writes the rule. Whenever something asks for the sctp module, modprobe now runs /bin/false instead of loading it. The second line prints modprobe’s active configuration, so you can see that the rule is really in effect. The third line unloads the module if it is already loaded.

Terminal showing the install sctp rule written, modprobe configuration confirming it, and modprobe failing to unload because the module is in use
Real output. Callout 1 is the rule as modprobe reads it, callout 2 is the unload failing.

Where my fix is incomplete

The unload failed with Module sctp is in use. My own test had loaded the module a minute earlier, and it stayed loaded with a reference count of 2 and one open SCTPv6 socket that I could not trace to a process. So on this server the rule is written and confirmed, but it only takes effect after the module is gone, which means after the next reboot. I did not reboot a live web server in the middle of writing this post.

The lesson for you is the order of operations. Write the rule before you run any SCTP test, or run the test on a throwaway machine. If you test first, you may have to reboot to get a clean state.

Step 4: update the kernel

The rule is a stopgap. The real fix is a kernel that contains the patch. On Ubuntu, install the update for your kernel flavor, then reboot, because a kernel update does nothing until you boot it. My earlier post on checking what the next reboot will boot shows how to confirm which kernel you will land on.

Caveats

I tested one Ubuntu 24.04 server running an Oracle cloud kernel. The tracker rows come from a page fetched today and may have changed. Search results list other kernel flaws with a 9.8 score in the same batch, and I verified only CVE-2026-64564. Blocking SCTP breaks software that needs it, so check ss -S -a and /proc/net/sctp for real users first and test on a non-production system.

FAQ

What is CVE-2026-64564?

A Linux kernel use-after-free in SCTP ASCONF handling, rated Critical with a CVSS score of 9.8 by the Ubuntu security tracker, published August 4, 2026.

My server does not use SCTP, am I safe?

Not necessarily. On my Ubuntu server the module was not loaded, but an ordinary user could load it by opening an SCTP socket. Block the module if you do not need it.

How do I disable SCTP on Ubuntu?

Run echo “install sctp /bin/false” | sudo tee /etc/modprobe.d/disable-sctp.conf. This is the mitigation Ubuntu lists, and it needs a reboot or an unload to take full effect if the module is already loaded.

Which Ubuntu kernel has the fix?

For Ubuntu 24.04 the tracker lists 6.8.0-147.147 for linux, 7.0.0-38.38~24.04.4 for linux-hwe-7.0 and 6.8.0-1064.67 for linux-oracle. The linux-oracle-6.17 line was shown as ignored because it is end of life.

Do I need to reboot after updating the kernel?

Yes. A new kernel only runs after a reboot, so check uname -r afterwards.

Sources