containerd: daemon crash when pulling an image with a crafted Content-Length header

Impact

A bug in containerd's image pull process can cause containerd to crash when downloading layers from an untrusted registry. When parallel layer fetch is enabled, an untrusted registry returning a crafted Content-Length header can trigger an unhandled memory allocation panic. This issue only affects configurations where concurrent_layer_fetch_buffer is set to enable parallel layer fetch; default configurations with this setting disabled are not affected. A daemon crash interrupts in-flight container operations and blocks new pod startup until containerd is restarted by a service manager, though existing running containers remain unaffected.

Patches

This bug has been fixed in containerd 2.4.2, 2.3.7, and 2.2.10. Users should update to these versions to resolve the issue.

Workarounds

Ensure concurrent_layer_fetch_buffer is set to 0 (the default) or omitted in containerd's configuration under [plugins."io.containerd.transfer.v1.local"] and [plugins."io.containerd.cri.v1.images"] to disable parallel layer fetch. Restrict pod image references to trusted registries (for example, using a Kubernetes ValidatingAdmissionPolicy or admission webhook).

Credits

The containerd project would like to thank Opensec Intelligence for responsibly disclosing this issue in accordance with the containerd security policy.

For more information

If you have any questions or comments about this…