Brief description:

SCTPhantom is a use-after-free in the SCTP Dynamic Address Reconfiguration (ASCONF, RFC 5061) subsystem of the Linux kernel that allows an unprivileged local user to gain superuser (root) privileges.

The root cause is an identity mismatch when processing an ASCONF chunk: the DEL-IP operation check is performed against the IPv4 packet source address (S), while further processing uses the transport selected via the Address Parameter (L). Because of this, the ordered sequence

passes the checks and removes transport(L), after which the wildcard operation DEL-IP 0.0.0.0 reuses the already freed pointer as a "persistent path". As a result, asoc->peer.primary_path and asoc->peer.active_path remain dangling pointers to the freed struct sctp_transport, and a subsequent call to getsockopt(SCTP_STATUS) dereferences them.

The vulnerable logic was introduced in Linux 2.6.25 (2007, commit 42e30bf3463c), meaning it has been present in the kernel for about 18 years.

Attack:

• requires no remote access — only an unprivileged local account
• does not require CAP_NET_ADMIN or CAP_SYS_ADMIN, works with the default seccomp profile active; ASCONF and AUTH are enabled per-socket via SCTP_ASCONF_SUPPORTED / SCTP_AUTH_SUPPORTED, so the net.sctp.addip_enable sysctl does not need to be changed
• is a working container-to-host escape primitive: the authors obtained host root in 6 out of 8 attempts; the final step is call_usermodehelper_exec(), which launches a process in the host's initial namespaces
• on failed exploitation it ends "cleanly", without a kernel panic, making detection harder
• the exploit chain reuses existing kernel code (data-oriented commit_creds()), without shellcode or classic ROP

Affected technologies:

• Linux kernel, net/sctp subsystem (sctp module), ASCONF handling in net/sctp/sm_make_chunk.c
• The sctp_diag module (depends on sctp), used for inspecting SCTP sockets

The vulnerability is exploitable only when SCTP is available: if the sctp module is not loaded and its autoloading is blocked, the vector is unavailable.

Targets confirmed by the authors (root obtained):

Fixed kernel versions:

Vendor kernels may contain a backport of the fix with an older version string — the kernel version alone is not a sufficient indicator of vulnerability; rely on the vendor's advisory or sources.

Attack vector and severity according to CVSS v4.0:

Base score: 8.5 (HIGH)

Vector: CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

What this fix does

The DaemonSet automatically, on every worker node of the cluster:

1. Checks the state of the modules — checks whether sctp and sctp_diag are loaded and with what refcnt. The check is intentionally passive: the DaemonSet does not open an SCTP socket before installing the blacklist, so as not to trigger autoloading of the module on a node where it is not yet loaded.
2. Checks whether SCTP is in use on the node — analyzes the module's refcnt and live records in /proc/net/sctp/assocs and /proc/net/sctp/eps. Kubernetes itself does not use SCTP, but user workloads may declare protocol: SCTP in a Service/Pod.
3. Blocks the vulnerable modules — creates /etc/modprobe.d/blacklist-sctp.conf with install and blacklist rules for sctp and sctp_diag.
4. Unloads the modules — runs rmmod for sctp_diag, then sctp (order matters: sctp_diag depends on sctp). If live SCTP connections are found, unloading is skipped unless FORCE_APPLY=true is explicitly set.
5. Verifies the mitigation — checks that the configuration exists, that modprobe sctp is rejected, and that creating an SCTP socket (socket(AF_INET, SOCK_STREAM, IPPROTO_SCTP)) no longer succeeds.
6. Monitors the state — every hour checks that the configuration is present, restores it if it disappears, and unloads the modules again if they have been reloaded.

Important: two possible outcomes on a node

The mitigation consists of two independent parts, and on some nodes only one of them is applied.

1. Blacklist (always applied, reliable). After /etc/modprobe.d/blacklist-sctp.conf is created, the sctp module can no longer be loaded — neither automatically on socket(AF_INET, SOCK_STREAM, IPPROTO_SCTP), nor by an explicit modprobe. This closes the vector on nodes where the module has not yet been loaded (the typical state: SCTP is not used by Kubernetes and is loaded only on demand).

2. Unloading the module from memory (not always possible). If sctp is already loaded, unloading it will most often fail. On tested Yandex Managed Kubernetes nodes (Ubuntu 22.04, kernel 5.15.0-181-generic), a freshly loaded sctp module that is not used by anyone already has refcnt=6 with an empty holders list and empty /proc/net/sctp/{assocs,eps}, and rmmod returns ERROR: Module sctp is in use. The counter does not decrease over time.

Hence two implications:

• refcnt is not an indicator that SCTP is in use — the DaemonSet outputs it for informational purposes only, and decides whether to unload based on live records in /proc/net/sctp/assocs and /proc/net/sctp/eps.
• on a node where sctp is already resident, the DaemonSet honestly reports ⚠ mitigation applied PARTIALLY. The blacklist is in place there (the module will not return after a reboot), but until reboot the node remains vulnerable. To fully close the vector, such nodes need to be rebooted or the node group recreated.

To find such nodes after rollout:

Compatibility with workloads

Important: the mitigation completely disables SCTP on the node.

Kubernetes and network plugins (Cilium, Calico) do not use SCTP for their own operation, so for the vast majority of clusters the mitigation is safe. However, if the cluster has workloads that use SCTP (for example, telecom applications, VoIP/SS7/Diameter signaling, Service or NetworkPolicy with protocol: SCTP), their traffic will stop working.

Check whether such objects exist in the cluster before rollout:

If SCTP is used on the node, the DaemonSet by default does not unload the module from memory, but only installs the blacklist (the module will not return after a node reboot) and writes a warning to the logs. To force unloading and break existing SCTP connections, set in the manifest:

Quick Start

1. Download the DaemonSet

Or clone the repository:

2. Apply the fix

3. Check the application status

4. View fix application logs

5. Find nodes where the mitigation was not fully applied

Example of successful application

Example of partial application (module was already loaded)

Such a node needs to be rebooted: the blacklist will no longer allow the module to load again.

Verifying mitigation effectiveness from a pod

The most demonstrative check is to reproduce the attacker's position: an unprivileged pod with dropped capabilities, as in the container escape chain.

Expected output on a protected node:

On an unprotected node, the output will be SCTP REACHABLE -> EXPLOITABLE, and the check itself will cause the sctp module to be autoloaded on that node (after which unloading it will most likely be impossible — see the section above). Do not run it on unprotected nodes unless necessary.

Manual vulnerability check

You can check the node state manually. Connect to the node via SSH and run:

Caution: running this check on a node where the module is not yet loaded will itself trigger its autoloading. Run it only after applying the mitigation, or deliberately.

Check the configuration:

Check that the vulnerable modules are not loaded:

Applying outside Kubernetes

If you need to apply the mitigation on regular hosts, a one-liner:

Removing the fix

If you need to remove the DaemonSet:

Important: Deleting the DaemonSet will not remove the configuration files from the nodes. The file /etc/modprobe.d/blacklist-sctp.conf will remain in place and will continue to protect the system.

To completely remove the fix from the nodes, connect to each node via SSH and manually delete the file:

Technical details

Permissions used:

• hostPID: true — for access to host processes via nsenter
• privileged: true — for writing to /etc and unloading kernel modules
• Volume mount / — for access to the host filesystem

Image: ubuntu:22.04

Resources:

• Init container: 10m CPU / 64Mi RAM (requests), 200m CPU / 128Mi RAM (limits)
• Monitor container: 5m CPU / 32Mi RAM (requests), 50m CPU / 64Mi RAM (limits)

Namespace: kube-system

Why the config has both install and blacklist: blacklist blocks loading by alias (including autoloading on socket(..., IPPROTO_SCTP)), but does not prevent an explicit modprobe sctp. The install sctp /bin/false line closes that path too.

Why the mitigation is not a substitute for a kernel update: blocking the module removes the vector, but the bug itself remains in the kernel. The permanent solution is updating the kernel to a fixed version (see the table above) or updating node images and recreating the node group.

Compatibility

• ✓ Yandex Managed Kubernetes
• ✓ Ubuntu 20.04
• ✓ Ubuntu 22.04
• ✓ Kubernetes 1.20+

License

Apache License 2.0

See LICENSE for details.

Support

If you encounter any issues, create an issue in the repository.