CVE-2021-43784: Overflow in netlink bytemsg length field allows attacker to override netlink-based container configuration

Published Dec 6, 2021
·
Updated

Impact

In runc, netlink is used internally as a serialization system for specifying the relevant container configuration to the C portion of our code (responsible for the based namespace setup of containers). In all versions of runc prior to 1.0.3, the encoder did not handle the possibility of an integer overflow in the 16-bit length field for the byte array attribute type, meaning that a large enough malicious byte array attribute could result in the length overflowing and the attribute contents being parsed as netlink messages for container configuration.

This vulnerability requires the attacker to have some control over the configuration of the container and would allow the attacker to bypass the namespace restrictions of the container by simply adding their own netlink payload which disables all namespaces.

Prior to 9c444070ec7bb83995dbc0185da68284da71c554, in practice it was fairly difficult to specify an arbitrary-length netlink message with most container runtimes. The only user-controlled byte array was the namespace paths attributes which can be specified in runc's config.json, but as far as we can tell no container runtime gives raw access to that configuration setting -- and having raw access to that setting would allow the attacker to disable namespace protections entirely anyway (setting them to /proc/1/ns/... for instance). In addition, each namespace path is limited to 4096 bytes (with only 7 namespaces supported by runc at the moment) meaning that even with custom namespace paths it appears an attacker still cannot shove enough bytes into the netlink bytemsg in order to overflow the uint16 counter.

However, out of an abundance of caution (given how old this bug is) we decided to treat it as a potentially exploitable vulnerability with a low severity. After 9c444070ec7bb83995dbc0185da68284da71c554 (which was not present in any release of runc prior to the discovery of this bug), all mount paths are included as a giant netlink message which means that this bug becomes significantly more exploitable in more reasonable threat scenarios.

The main users impacted are those who allow untrusted images with untrusted configurations to run on their machines (such as with shared cloud infrastructure), though as mentioned above it appears this bug was not practically exploitable on any released version of runc to date.

Patches The patch for this is d72d057ba794164c3cce9451a00b72a78b25e1ae and runc 1.0.3 was released with this bug fixed.

Workarounds To the extent this is exploitable, disallowing untrusted namespace paths in container configuration should eliminate all practical ways of exploiting this bug. It should be noted that untrusted namespace paths would allow the attacker to disable namespace protections entirely even in the absence of this bug.

References commit d72d057ba794 ("runc init: avoid netlink message length overflows") https://bugs.chromium.org/p/project-zero/issues/detail?id=2241

Credits Thanks to Felix Wilhelm from Google Project Zero for discovering and reporting this vulnerability. In particular, the fact they found this vulnerability so quickly, before we made a 1.1 release of runc (which would've been vulnerable) was quite impressive.

For more information If you have any questions or comments about this advisory: Open an issue in our repo

Other sources

In runc, netlink is used internally as a serialization system for specifying the relevant container configuration to the C portion of our code (responsible for the based namespace setup of containers). In all versions of runc prior to 1.0.3, the encoder did not handle the possibility of an integer overflow in the 16-bit length field for the byte array attribute type, meaning that a large enough malicious byte array attribute could result in the length overflowing and the attribute contents being parsed as netlink messages for container configuration.

References: https://github.com/opencontainers/runc/security/advisories/GHSA-v95c-p5hm-xq8f https://www.openwall.com/lists/oss-security/2021/12/06/1

Red Hat

Open Container Initiative runc could allow a remote authenticated attacker to bypass security restrictions, caused by an integer overflow in netlink bytemsg length field. By sending a specially-crafted request, an attacker could exploit this vulnerability to override netlink-based container configuration to disable namespace protections entirely.

IBM

runc is a CLI tool for spawning and running containers on Linux according to the OCI specification. In runc, netlink is used internally as a serialization system for specifying the relevant container configuration to the C portion of the code (responsible for the based namespace setup of containers). In all versions of runc prior to 1.0.3, the encoder did not handle the possibility of an integer overflow in the 16-bit length field for the byte array attribute type, meaning that a large enough malicious byte array attribute could result in the length overflowing and the attribute contents being parsed as netlink messages for container configuration. This vulnerability requires the attacker to have some control over the configuration of the container and would allow the attacker to bypass the namespace restrictions of the container by simply adding their own netlink payload which disables all namespaces. The main users impacted are those who allow untrusted images with untrusted configurations to run on their machines (such as with shared cloud infrastructure). runc version 1.0.3 contains a fix for this bug. As a workaround, one may try disallowing untrusted namespace paths from your container. It should be noted that untrusted namespace paths would allow the attacker to disable namespace protections entirely even in the absence of this bug.

Launchpad

Affected Software

6 affected componentsFixes available
go/github.com/opencontainers/runc<1.0.3
1.0.3
debian/runc<=1.0.0~rc93+ds1-5+deb11u3
1.0.0~rc93+ds1-5+deb11u51.1.5+ds1-1+deb12u11.1.15+ds1-2
linuxfoundation Runc<1.0.3
Debian Debian Linux=9.0
redhat/runc<1.0.3
1.0.3
IBM Concert Software<=1.0.0 - 1.0.1

Event History

Dec 6, 2021
CVE Published
via MITRE·12:00 AM
Data Sourced
via MITRE·12:00 AM
DescriptionSeverityWeakness
Data Sourced
via Red Hat·02:12 PM
DescriptionSeverityAffected Software
Dec 7, 2021
Advisory Published
via GitHub·09:22 PM
May 20, 2024
Data Sourced
via Launchpad·07:54 PM
Description
Sep 13, 2024
Data Sourced
via Ubuntu·08:14 PM
RemedyDescriptionSeverityAffected Software
Feb 4, 2025
Data Sourced
via IBM·12:00 AM
DescriptionAffected Software

Parent advisories

This vulnerability appears in the following advisories.

Free Weekly Intel

Don't miss critical vulnerabilities

Join thousands of security professionals who receive our weekly digest of trending CVEs, zero-days, and exploited vulnerabilities.

No spam. Unsubscribe anytime.

Frequently Asked Questions

1

What is CVE-2021-43784?

CVE-2021-43784 is a vulnerability in runc, a CLI tool for running containers, that allows an attacker to escape container isolation and execute malicious code on the host system.

2

What is the impact of CVE-2021-43784?

The impact of CVE-2021-43784 is that an attacker can gain access to the host system and execute arbitrary code.

3

Which software versions are affected by CVE-2021-43784?

Versions up to and including runc 1.0.3 are affected by CVE-2021-43784.

4

How can I fix CVE-2021-43784?

To fix CVE-2021-43784, update to runc version 1.0.4 or later.

5

Where can I find more information about CVE-2021-43784?

You can find more information about CVE-2021-43784 in the following references: [link1](https://github.com/opencontainers/runc/security/advisories/GHSA-v95c-p5hm-xq8f), [link2](https://bugs.chromium.org/p/project-zero/issues/detail?id=2241), [link3](https://github.com/opencontainers/runc/commit/9c444070ec7bb83995dbc0185da68284da71c554).

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203