CVE-2021-43784 is a medium-severity (CVSS 5) CWE-190 vulnerability in github.com/opencontainers/runc. 1 public exploit reference exists, so weaponization risk is real. A fix is available for github.com/opencontainers/runc — see the affected versions and patch details below.
Overflow in netlink bytemsg length field allows attacker to override netlink-based container configuration in RunC
Exploitation Status
No confirmed exploitation observed yet
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for CVE-2021-43784.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
CVE-2021-43784 by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.
Where this sits among everything scored
Of 385,738 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.
Real-World Exposure
github.com/opencontainers/runcReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.
Description
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
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/opencontainers/runc | all versions | 1.0.3go get github.com/opencontainers/runc@v1.0.3 |
Affected Products
debian linuxdebianrunclinuxfoundationResearch use only. For defensive security, authorized penetration testing, and academic research only. Never execute exploit code against systems without explicit written authorization.
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/opencontainers/runc, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update github.com/opencontainers/runc to 1.0.3 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2021-43784 is resolved across your whole dependency graph.
Workarounds
Stop feeding it untrusted input: reject or quarantine files and payloads from unverified sources until you can upgrade, restrict accepted formats to the ones you actually need, and run the parsing or decoding step in a least-privileged sandbox or short-lived worker so a crash or corrupted read cannot reach the rest of the process.
Fixing This On Your OS
If you run this on a Linux distribution, patch through your package manager against the distro's own security advisory below — it tracks the exact backported fix for your release, which can ship on a different timeline (and sometimes a different severity) than the upstream project.
Before runC 1.0.3, the only user-controlled byte array (used to exploit this vulnerability) was the namespace paths attributes, located in runC's config.json. Having raw access to that setting would allow the attacker to disable namespace protections entirely. This issue means that in practice, it was fairly difficult…
| Product | Fixed in | Advisory |
|---|---|---|
| Red Hat Enterprise Linux 9 | container-tools:latest/runc-4:1.1.9-1.el9 | RHSA-2023:6380 |
Frequently Asked Questions
Is CVE-2021-43784 in your dependencies?
Find it across Go, including transitive dependencies.