CVE-2024-40635 - How a UID Overflow in containerd Let Containers Run as Root

Published: June 2024

By: Security Insights Editorial

Containerd, a core piece of many container stacks (including Docker and Kubernetes), was recently at the center of a critical security bug. In this post, we’ll break down what happened with CVE-2024-40635, what it means for your containers, show you the vulnerability with code snippets, and tell you how to stay safe.

What is containerd?

containerd is a high-performance container runtime used for managing the lifecycle of containers. A lot of popular container orchestrators build on top of containerd.

What’s the problem?

Before version 1.6.38 (also in 1.7.27, and 2..4), containerd had a type confusion bug when handling containers configured with a User set to a numerical UID and GID (for example, User: 400000000:400000000).

Normally, to run a container as a non-root user, you might specify the UID/GID like

spec:
  containers:
    - name: my-app
      image: my-image
      securityContext:
        runAsUser: 1001
        runAsGroup: 1001

But when the UID or GID values exceed the maximum for a signed 32-bit integer (2147483647), containerd overflows and wraps the value. Ultimately, the container may run as UID (root!) even though it’s specified to run as a high, "unprivileged" UID.

Why does this happen?

It's classic integer overflow. Linux UIDs and GIDs are normally 32-bit numbers. When given a number like 400000000 (bigger than 2,147,483,647), the internal conversion ends up treating that effectively as zero (root).

For example

int32_t large_uid = 400000000;  // larger than max 32bit signed int
printf("UID: %d\n", large_uid);  // prints -294967296 or wraps around

In Go (used by containerd), the overflow causes values to get misinterpreted as if sufficiently large.

The impact

If you expected your container to run as a random non-root user (for isolation), you could actually be running with root privileges inside the container. That’s a big deal if you have any untrusted code or multi-tenant workloads relying on running as non-root for security.

Who can exploit this?

- Attackers with the ability to craft or edit container manifests (e.g., in Kubernetes YAMLs, docker-compose, or OCI specs).

Suppose someone can deploy a pod or container and they submit

securityContext:
  runAsUser: 400000000
  runAsGroup: 400000000

containerd processes the spec. The numbers overflow, UID 400000000 is passed in but ends up interpreted as UID . Now, the process runs as root.

Try running this with a vulnerable containerd

FROM alpine:3.18
USER 400000000:400000000
CMD id

Build and run the container. You would expect this to show

uid=400000000 gid=400000000 groups=400000000

But on a vulnerable containerd (before fixed versions), it prints

uid=(root) gid=(root) groups=(root)

References

- containerd Security Advisory GHSA-xxxx-xxxx-xxxx (Official Advisory)
- CVE-2024-40635 on NVD
- containerd Changelog

1. Upgrade containerd

Update to containerd version 1.6.38, 1.7.27, or 2..4 (or later). These versions include proper handling of UID overflows.

Only allow trusted images and prevent untrusted users from mounting their own containers.

- Validate manifests or Dockerfiles to ensure UIDs are within safe range (e.g., less than 2147483647).

3. Audit Your Deployments

- Search for non-root UIDs above the 32-bit signed integer limit in any self-written or 3rd party manifests.

4. Use Tools

- Use image scanning and policy enforcement tools (like Open Policy Agent or Kyverno) to block containers that use suspicious UID values.

Kyverno rule example

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: validate-uid-range
spec:
  validationFailureAction: enforce
  rules:
    - name: check-uid-range
      match:
        resources:
          kinds:
            - Pod
      validate:
        message: "runAsUser/runAsGroup must be below 2,147,483,647"
        pattern:
          spec:
            containers:
              - securityContext:
                  runAsUser: "<2147483647"
                  runAsGroup: "<2147483647"

Final Thoughts

This vulnerability is a reminder: even simple numbers can hide big risks. Always keep your dependencies up-to-date, and review security advisories for core infrastructure like containerd.

If you manage a cluster that uses containerd, you must patch now. Until then, limit what images and manifests your users can deploy.

For more details and the official fix, see containerd’s advisory.

Timeline

Published on: 03/17/2025 22:15:13 UTC