Apptainer setuid-root ext4 use-after-free can cause kernel denial of service and potential privilege escalation

Apptainer is an open source container platform for Linux. There is an ext4 use-after-free flaw that is exploitable through versions of Apptainer < 1.1.0 and installations that include apptainer-suid < 1.1.8 on older operating systems where that CVE has not been patched. That includes Red Hat Enterprise Linux 7, Debian 10 buster (unless the linux-5.10 package is installed), Ubuntu 18.04 bionic and Ubuntu 20.04 focal. Use-after-free flaws in the kernel can be used to attack the kernel for denial of service and potentially for privilege escalation. Apptainer 1.1.8 includes a patch that by default disables mounting of extfs filesystem types in setuid-root mode, while continuing to allow mounting of extfs filesystems in non-setuid "rootless" mode using fuse2fs. Some workarounds are possible. Either do not install apptainer-suid (for versions 1.1.0 through 1.1.7) or set allow setuid = no in apptainer.conf. This requires having unprivileged user namespaces enabled and except for apptainer 1.1.x versions will disallow mounting of sif files, extfs files, and squashfs files in addition to other, less significant impacts. (Encrypted sif files are also not supported unprivileged in apptainer 1.1.x.). Alternatively, use the limit containers options in apptainer.conf/singularity.conf to limit sif files to trusted users, groups, and/or paths, and set allow container extfs = no to disallow mounting of extfs overlay files. The latter option by itself does not disallow mounting of extfs overlay partitions inside SIF files, so that's why the former options are also needed.

• Apptainer: The normalized affected fact marks versions < 1.1.8 as affected. The upstream advisory also lists < 1.1.8 as affected and 1.1.8 as patched. Exposure is tied to setuid-root use; the advisory specifically identifies Apptainer < 1.1.0 and installations containing apptainer-suid < 1.1.8.
• Older operating systems: Red Hat Enterprise Linux 7, Debian 10 buster unless the linux-5.10 package is installed, Ubuntu 18.04 bionic, and Ubuntu 20.04 focal, when the underlying kernel issue remains unpatched.
• Related scope: The CNA advisory describes all Singularity versions in their default configuration on the listed systems. Sylabs disputes treating this as a Singularity product vulnerability and states that the kernel issue should be patched; this is a scope disagreement rather than a change to the normalized Apptainer product record.
• Distribution packages: The Debian tracker lists singularity-container in unstable as fixed at 3.11.4+ds1-1. SUSE lists apptainer >= 1.3.0-bp155.3.3.2 for SUSE Package Hub 15 SP5 and openSUSE Leap 15.5, and apptainer >= 1.1.8-1.1 for openSUSE Tumbleweed. These boundaries apply to the named package branches and do not establish coverage for every parallel or subsequent branch.

This is a CWE-416: Use After Free flaw in the Linux kernel's ext4 filesystem driver. In setuid-root mode, Apptainer allows users to mount extfs filesystems, including ext3 handled by the ext4 driver, and squashfs through kernel drivers while retaining write access to the raw filesystem data. At a high level, the sequence is: a user supplies or runs a specially crafted extfs container image; the setuid-root runtime asks the kernel to mount the data; the kernel processes attacker-controlled filesystem data and may trigger the use-after-free. The attacker-controlled object can be a crafted extfs container image or an extfs overlay partition inside a SIF file. The available evidence does not identify a function, payload, or reproducible privilege-escalation path; the vulnerable implementation detail is unsafe kernel memory lifetime handling.

Reachability is local: an attacker needs access to run, or cause execution of, a container through the affected setuid-root path. The record indicates low privileges and no user interaction; no remote network path is described. The CNA advisory requires a specially crafted filesystem image or overlay, while the normalized record describes low attack complexity; the evidence does not provide a reproducible exploit sequence. The supplied record marks public exploitation as false and does not record known exploitation; that status should not be read as proof that exploitation has never occurred. Sylabs reports that a specially crafted extfs image or SIF overlay can trigger denial of service on affected hosts, while describing the issue as residing in the kernel rather than as a Singularity product vulnerability.

The primary technical outcome is denial of service against the host kernel. Because a kernel use-after-free is reachable through a privileged mounting path, corruption of kernel state could potentially affect confidentiality or integrity and may be usable for privilege escalation; the available evidence does not prove that path. The scope can extend from the container runtime into the host kernel rather than remaining confined to one container. Organisational consequences may include disruption of shared container or HPC workloads and, if privilege escalation succeeds, possible compromise of host data or controls. No named victim, campaign, or breach is established by the evidence.

On a vulnerable host, a local container user may be able to crash or destabilize the host kernel by running a specially crafted filesystem image through setuid-root Apptainer. If privilege escalation is achieved, the impact could extend from service availability to host data confidentiality and integrity, but that outcome is described as potential rather than demonstrated by the supplied evidence. Disabling setuid mounts or moving to rootless execution can reduce exposure only with operational trade-offs, including loss of some SIF, extfs, squashfs, encrypted SIF, execution-control, supplementary-group, or host filesystem ACL behavior depending on the runtime and configuration. On shared HPC or container hosts, a kernel denial of service could interrupt multiple workloads.

1. Install the upstream 1.1.8 fix, or the exact vendor security package documented for the operating-system branch in use. The Apptainer fix disables extfs mounts in setuid-root mode by default while continuing to allow rootless extfs mounts through fuse2fs.
2. Patch the host kernel using the operating system vendor's update and reboot as required. The Apptainer change is defense in depth and does not replace patching the underlying kernel issue.
3. If an upgrade is not immediately possible, for versions 1.1.0 through 1.1.7, remove apptainer-suid or set allow setuid = no in apptainer.conf. This requires unprivileged user namespaces and can disable mounting of SIF, extfs, and squashfs files along with other functionality. For Singularity deployments, use the corresponding singularity.conf setting.
4. If setuid operation must remain enabled, use the limit containers options in apptainer.conf or singularity.conf to restrict SIF files to trusted users, groups, or paths, and set allow container extfs = no to block extfs overlay files. The latter setting alone does not block extfs overlay partitions inside SIF files.
5. Validate workflow impact before enabling rootless mode or disabling setuid, especially for encrypted SIF, execution-control, supplementary-group, and host filesystem ACL requirements.

1. Inventory Apptainer installations, the apptainer-suid package, and whether the binary was built with the setuid-root portion.
2. Inspect apptainer.conf and related configuration to identify allow setuid, allow setuid-mount, allow container extfs, and limit containers, and to confirm whether unprivileged user namespaces are enabled.
3. Compare the host OS and kernel with the vendor's patch status for the underlying ext4 issue, especially on the older RHEL, Debian buster, and Ubuntu bionic or focal branches identified in the affected scope.
4. Review audit records and execution history for extfs mounts, extfs overlays, or SIF files mounted through the setuid-root path. This is behavior-based review, not a confirmed IOC.
5. No specific log event, payload, or indicator is provided by the sources. Absence of such evidence does not prove that a host is safe.