systemd-tmpfiles: uncontrolled recursion on deeply nested /tmp directories stalls boot

CVSS 5.5CVE-2021-3997Kernel, userspace & hypervisorcurated

Impact

systemd-tmpfiles recurses without bound when cleaning /tmp, so a local user who creates a deeply nested directory tree there can exhaust the stack and make systemd-tmpfiles fail at boot time. On a GPU node that matters because the damage surfaces at the next reboot rather than when it is planted: a node that was drained for a firmware flash or kernel update comes back wedged in early boot, and the operator has to recover it out of band instead of returning it to the scheduler. Availability only - no data exposure, no privilege gain. Shared multi-tenant nodes with a world-writable /tmp are the exposed case; nodes where tenants get per-pod ephemeral mounts are not.

Who can reach it

Local unprivileged user with write access to /tmp on the host (a tenant shell, or a container that shares the host /tmp). No special capabilities and no authentication beyond an account.

What to do

Update systemd from your distribution (upstream commit 5b1cf7a9be37, Gentoo GLSA 202305-15) and reboot the node to be running the fixed tmpfiles at the next boot; a package update alone leaves the in-flight boot path untested. Until then, do not expose the host /tmp to tenant workloads. Low urgency: a DoS that needs a local account and a reboot to trigger.

References

https://nvd.nist.gov/vuln/detail/CVE-2021-3997 https://access.redhat.com/security/cve/CVE-2021-3997 https://github.com/systemd/systemd/commit/5b1cf7a9be37e20133c0208005274ce4a5b5c6a1 https://www.openwall.com/lists/oss-security/2022/01/10/2

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.