A newly disclosed Linux kernel local privilege escalation vulnerability, reported by Theori/Xint, can allow any unprivileged local user to obtain root privileges using a 732-byte Python script. The exploit works reliably on the first attempt, does not depend on a race condition, and does not require adaptation to a specific kernel build. Although the vulnerability has a CVSS score of 7.8 (High), its real-world impact can be effectively critical in shared-kernel and multi-tenant environments.
The bug
The issue stems from a logic flaw in the kernel’s algif_aead component, introduced in Linux kernel 4.14 in July 2017. The vulnerable path is reachable through AF_ALG and splice() and enables a deterministic 4-byte write into the page cache of any readable file, including setuid binaries.
- The exploit does not rely on a race condition, does not require kernel-specific offsets, and works on the first attempt.
- The file on disk remains unchanged, meaning traditional file-integrity monitoring tools are unlikely to detect the modification.
- Because the page cache is shared at the host level, this vulnerability can become a basis for container escape on Kubernetes nodes from any pod where processes are able to create AF_ALG sockets.
Who is affected
The vulnerability affects Linux kernels starting from version 4.14 up to the patched versions. Theori confirmed root privilege escalation on Ubuntu 24.04 LTS, Amazon Linux 2023, RHEL 10.1, and SUSE 16. The same exploit also works without modification on Debian, Fedora, Rocky, Alma, Oracle, and Arch. The issue is fixed in kernel versions 6.18.22, 6.19.12, and 7.0.
What to do
At the time of disclosure, most Linux distributions had not yet shipped patched kernels. Mitigation should be applied first, followed by kernel updates as soon as they become available.
1. Disable algif_aead on every host:
echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf rmmod algif_aead 2>/dev/null || trueThis mitigation is safe to apply. It does not affect dm-crypt, kTLS, IPsec, OpenSSL, SSH, or kernel keyring cryptography. The impact is limited to applications that explicitly use the OpenSSL afalg engine.
2. Block AF_ALG through seccomp for untrusted workloads, including Kubernetes pods, CI runners, and agent sandboxes.
3. Patch the kernel as soon as the relevant distribution provides the fix, then reboot the system.
4. Recommended prioritization: multi-tenant Kubernetes nodes first, followed by CI runners, production servers, and workstations.
For cloud-native teams
Kernel CVEs are not reflected in image SBOMs, so detection and exposure assessment should happen at the node level. Workloads running with hardware virtualization, such as Firecracker for Lambda or Fargate, or with kernel reimplementations such as gVisor or V8 isolates, are not exposed to the host kernel’s AF_ALG path.
