Linux kernel wave 28–30 May 2026: CVE-2026-46227 SCTP `SCTP_SENDALL` type confusion as an unprivileged LPE primitive in a wave of 117 CVEs

TL;DR — the 90-second summary

What was published?

An unusual concentration of 117 Linux kernel CVEs with CVSS ≥ 7 within 48 hours (28–30 May 2026, OpenCVE filter vendor:linux AND cvss31>=7 AND created<=2d). Operationally substantial: CVE-2026-46227: „sctp: revalidate list cursor after sctp_sendmsg_to_asoc() in SCTP_SENDALL“. Use-after-free plus type confusion in the path that walks ep->asocs via list_for_each_entry_safe() — the bug is explicitly noted as „reachable from CapEff=0“, the type confusion path gives a controlled indirect call through the function pointer outqueue.sched->init_sid. Companion findings with their own leverage: CVE-2026-46154 (sched_ext cgroup UAF), CVE-2026-46209 and CVE-2026-46215 (drm/gem prime-swap race), CVE-2026-46197 (drm/amdkfd SVM nattr OOB), plus cluster batman-adv and drm/amdgpu/vcn3/vcn4.

How bad?

CVE-2026-46227 is the only class in the wave with an explicit unprivileged-path statement and a documented exploit handle (controlled indirect call). That is the operationally most important class. The other wave content is largely local UAF/race/OOB classes with limited exploitability. In a container stack, /dev/dri access is not unusual, so the DRM classes are relevant there.

Which kernel versions are affected?

The individual CVEs hit different upstream tags. For CVE-2026-46227: all SCTP-carrying kernels from the commit that introduced list_for_each_entry_safe() in the SCTP_SENDALL loop, plus all backports into the LTS kernels (6.1, 6.6, 6.12 LTS lines). Distribution fixes flow into the next kernel Z-stream updates for RHEL/Rocky/Alma, Debian, Ubuntu, openSUSE.

Am I affected?

Directly affected are all Linux servers whose kernel has the SCTP socket code loaded (module sctp or built in). SCTP is loaded in many distributions as a module the moment a process creates an SCTP socket — and that can be an unprivileged process. Anyone not actively using SCTP should unload the module from the kernel or block it via blacklist — mitigation class zero. Container stacks with workloads that need /dev/dri access or GPU compute are relevant via the drm/ cluster.

Immediate mitigation?

Three steps. First, check SCTP usage (lsmod | grep sctp); if not actively used, blacklist the module (echo "blacklist sctp" > /etc/modprobe.d/blacklist-sctp.conf and modprobe -r sctp). Second, for active SCTP users, plan the distribution kernel Z-stream update; in the meantime restrict unprivileged access to AF_INET+SOCK_SEQPACKET+IPPROTO_SCTP socket creation via seccomp profiles. Third, standard kernel update discipline within 7–14 days.

Severity?

Hero badge high. Active exploitation as of 30 May is not publicly documented. SCTP LPE classes have historically seen PoCs within weeks.

What happened

An OpenCVE query with vendor:linux AND cvss31>=7 AND created<=2d on 30 May 2026 returns 117 hits — noticeably more than the subjective impression of a typical 48-hour window in the past few months. Most of these hits are classic Linux kernel CNA disclosures (Linux kernel CVE team under the kernel.org CNA), published in a concentrated drop cycle. By content the wave spreads across multiple subsystem clusters — drm/amdgpu/vcn (GPU driver paths), batman-adv (mesh networking), drm/gem (Generic Memory Manager), media/iris (Qualcomm Iris video codec in staging), sched_ext (eBPF-based scheduler), and individual cases like SCTP, HID PlayStation, drm/amdkfd, xe.

The substantial finding in the wave is CVE-2026-46227 — „sctp: revalidate list cursor after sctp_sendmsg_to_asoc() in SCTP_SENDALL“. The bug sits in the SCTP_SENDALL path of sctp_sendmsg(), which walks the list of SCTP associations of an endpoint (ep->asocs) with list_for_each_entry_safe(). This iteration variant caches the next list pointer (@tmp) before the loop body runs. The problem: the loop body calls sctp_sendmsg_to_asoc(), which can drop the socket lock in sctp_wait_for_sndbuf(). While the lock is dropped, another thread can migrate the cached association object via SCTP_SOCKOPT_PEELOFF to a new endpoint and optionally close the new socket — which frees the association. Alternatively, a network ABORT can free the association completely.

The consequence on re-lock: @asoc is revalidated, but @tmp (the cached next pointer) is not. After a successful return the iterator advances to the stale @tmp — either freed (use-after-free) or, if the association was migrated, to a struct list_head * of another endpoint list (type confusion). The description in the upstream commit is explicit: „Both are reachable from CapEff=0; the type-confusion path gives controlled indirect call via the outqueue.sched->init_sid pointer.“ Unprivileged exploitation, with an exploitable indirect call.

The patch fixes the flaw by re-deriving @tmp from @asoc after every sctp_sendmsg_to_asoc() return.

Technical analysis

Structurally CVE-2026-46227 belongs to a bug class that recurs in Linux kernel networking code: list iteration with lock drop. When an iteration over a data structure releases the lock in between (for IO, sleep, wait), all cached pointers must be revalidated — not only the current one, but also all helper pointers. This class has a long history in the SCTP subsystem (commit ba59fb027307 from 2019, „sctp: walk the list of asoc safely“, was a similar correction).

The specific point in CVE-2026-46227 is the explicit type-confusion path. Use-after-free on a previously freed object is a class that has become significantly harder to exploit in recent years thanks to UAF defences (SLUB hardening, randomised slab layout, KASAN in production builds). Type confusion is a different class — memory is not freed but interpreted as a different type, and if that other type happens to carry function pointers, the indirect-call path is right there.

Methodologically valuable is the explicit CapEff=0 statement. Linux kernel CVEs in recent years often do not clearly state which capabilities an attacker needs. CVE-2026-46227 breaks with this tendency and says explicitly: no special capabilities required, the bug path is reachable from any unprivileged process. That is the kind of clarity that makes patch policy decisions easier.

Companion findings: CVE-2026-46154 (sched_ext cgroup UAF) is relevant for container stacks using sched_ext. CVE-2026-46209/-46215 (drm/gem prime-swap race) are local with /dev/dri access (containers with rendering workloads). CVE-2026-46197 (drm/amdkfd SVM nattr OOB) for AMD ROCm workloads. Clusters batman-adv and drm/amdgpu/vcn3/vcn4 are mostly not Mittelstand-relevant.

What this means for the Mittelstand

For the German Mittelstand, the substantial leverage of the wave sits with two classes.

First class: CVE-2026-46227 SCTP. The core question is whether the sctp kernel module is loaded on your Linux server estate and whether unprivileged processes can open SCTP sockets. In standard distributions sctp is available as a module and is loaded automatically the moment a process creates an SCTP socket — typical of telco applications (M3UA, Diameter, SIGTRAN), of some cluster filesystem setups, and rarely of P2P or latency-optimised applications. If your platform does not use SCTP actively — the typical configuration for TYPO3/Sylius/Symfony web stacks — mitigation is simple: disable sctp via the modprobe blacklist, unload the module, done.

Second class: CVE-2026-46154 sched_ext cgroup UAF. Relevant for container stacks that have enabled sched_ext — which in May 2026 is still an exception in the German Mittelstand, because sched_ext is not yet default-active in most distros.

The other wave classes (drm/ cluster, batman-adv, HID, media/iris) are less acute in the Mittelstand standard setting — either because the specific hardware is not in the server estate, or because the specific configuration (/dev/dri access from containers) is rarely used.

On the compliance side the wave acts as a patch-policy test. NIS-2 Art. 21 demands concrete patch discipline for the affected sectors — a wave with 117 CVEs in 48 hours is exactly the kind of disclosure event against which to test your own patch policy. Anyone with an automated SBOM workflow with kernel state tracking sees the relevant hits for their estate within an hour. GDPR Art. 32 is touched indirectly — a Linux server with an LPE flaw processing personal data is a technical-measures gap.

What this means for technical development

Architecturally the wave and especially CVE-2026-46227 force three disciplines.

First, kernel module hygiene. Every Linux server loads a number of kernel modules not needed by the concrete workload — network protocols (SCTP, DCCP, RDS, TIPC), filesystem drivers (cramfs, freevxfs, jffs2, hfs), device drivers for hardware that is not present. A good hardening step for every server is a modprobe blacklist for unused modules — the CIS benchmark pattern, described in BSI Grundschutz, DISA STIG and many Mittelstand hardening guides. CVE-2026-46227 is exactly the class that makes this discipline worthwhile.

Second, container capability audit. Which capabilities do your containers have? Which do they actually need? /dev/dri access for rendering workloads makes sense but should not be default-mounted in every container. SCTP socket creation can be blocked via seccomp — anyone with a restrictive seccomp profile (default for Kubernetes PodSecurityStandards restricted) blocks the whole class of SCTP bugs already at the container boundary.

Third, kernel patch pipeline tempo. The wave shows that Linux kernel CVE disclosure in 2026 runs at higher frequency. Anyone optimised for a monthly kernel patch cycle in the Mittelstand is too slow in 2026 — weekly updates for container images, at least 14-day updates for bare-metal hosts are the new minimum cadence.

Concrete recommendation

In this order. First, SCTP inventory today: on each Linux host check whether sctp is loaded as a module (lsmod | grep sctp) and whether the workload uses SCTP actively. If SCTP is not used, disable via modprobe blacklist (echo "blacklist sctp" > /etc/modprobe.d/blacklist-sctp.conf) and unload the module (modprobe -r sctp). That structurally mitigates CVE-2026-46227 on this host regardless of kernel patch state. Second, for active SCTP users: wait for the distribution kernel Z-stream update with the upstream backport; in the meantime check whether SCTP socket creation from unprivileged processes really needs to be allowed (restrict via seccomp profile if not). Third, container stack audit for sched_ext: check whether sched_ext is enabled in your container cluster; if so, set CVE-2026-46154 on the patch list. Fourth, /dev/dri audit: in the container workload definition check which containers have /dev/dri access; evaluate whether that is really necessary. Fifth, set up a kernel update pipeline if not already in place: for container base images a weekly re-build cadence, for bare-metal hosts a 14-day patch pipeline with automated reboot planning. Sixth, SBOM track for the kernel state: include the kernel package state per host and per container image in the SBOM workflow.

If these steps do not run from your own capacity, talk to me: I deliver platforms in which kernel module hygiene, container capability audit and patch pipeline tempo sit as a continuous process.

This post reflects my technical and strategic assessment. It does not replace legal advice or a data protection impact assessment.

Sources

• OpenCVE — CVE-2026-46227: SCTP SCTP_SENDALL UAF + Type Confusion (30 May 2026)
• OpenCVE — Linux Kernel CVE wave (query 30 May 2026, 117 hits)
• Red Hat Customer Portal — CVE-2026-46227 (as of 30 May 2026)
• xairy/linux-kernel-exploitation — Linux kernel security exploitation collection
• Linux Kernel Documentation — SCTP (as of 30 May 2026)