Last updated 28 September 2026

lxc-user-nic in lxc through 5.0.1 is installed setuid root, and may allow local users to infer whether any file exists, even within a protected directory tree, because "Failed to open" often indicates that a file does not exist, whereas "does not refer to a network namespace path" often indicates that a file exists. NOTE: this is different from CVE-2018-6556 because the CVE-2018-6556 fix design was based on the premise that "we will report back to the user that the open() failed but the user has no way of knowing why it failed"; however, in many realistic cases, there are no plausible reasons for failing except that the file does not exist.

https://github.com/MaherAzzouzi/CVE-2022-47952 https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1783591/comments/45 https://github.com/lxc/lxc/blob/0b83d71c2c8f3bac9503f894cd84584f79258bb3/lxc.spec.in#L274 https://github.com/lxc/lxc/blob/0b83d71c2c8f3bac9503f894cd84584f79258bb3/src/lxc/cmd/lxcusernic.c#L1085-L1104

[[ Patch CRD: 2019-02-11 15:00 CET ]] [[ Exploit Code CRD: 2019-02-18 15:00 CET ]]

Hello,

I am one of the maintainers of runc (the underlying container runtime underneath Docker, cri-o, containerd, Kubernetes, and so on). We recently had a vulnerability reported which we have verified and have a patch for.

The researchers who found this vulnerability are: Adam Iwaniuk Borys Popławski

In addition, Aleksa Sarai (me) discovered that LXC was also vulnerable to a more convoluted version of this flaw.

== OVERVIEW ==

The vulnerability allows a malicious container to (with minimal user interaction) overwrite the host runc binary and thus gain root-level code execution on the host. The level of user interaction is being able to run any command (it doesn't matter if the command is not attacker-controlled) as root within a container in either of these contexts:

Creating a new container using an attacker-controlled image. Attaching (docker exec) into an existing container which the attacker had previous write access to.

This vulnerability is not blocked by the default AppArmor policy, nor by the default SELinux policy on Fedora[++] (because container processes appear to be running as containerruntimet). However, it is blocked through correct use of user namespaces (where the host root is not mapped into the container's user namespace).

Our CVSSv3 vector is (with a score of 7.2):

AV:L/AC:H/PR:L/UI:R/S:C/C:N/I:H/A:H

The assigned CVE for this issue is CVE-2019-5736.

[++]: This is only the case for the "moby-engine" package on Fedora. The "docker" package as well as podman are protected against this exploit because they run container processes as containert.

== PATCHES ==

I have attached the relevant patch which fixes this issue. This patch is based on HEAD, but the code in libcontainer/nsenter/ changes so infrequently that it should apply cleanly to any old version of the runc codebase you are dealing with.

Please note that the patch I have pushed to runc master[1] is a modified version of this patch -- even though it is functionally identical (though we would recommend using the upstream one if you haven't patched using the attached one already).

== NON-ESSENTIAL EXPLOIT CODE ==

Several vendors have asked for exploit code to ensure that the patches actually solve the issue. Due to the severity of the issue (especially for public cloud vendors), we decided to provide the attached exploit code. This exploit code was written by me, and is more generic than the original exploit code provided by the researchers and works against LXC (it could likely be used on other vulnerable runtimes with no significant modification). Details on how to use the exploit code are provided in the README.

As per OpenWall rules, this exploit code will be published publicly 7 days after the CRD (which is 2019-02-18). If you have a container runtime, please verify that you are not vulnerable to this issue beforehand.

== IMPACT ON OTHER PROJECTS ==

It should be noted that upon further investigation I've discovered that LXC has a similar vulnerability, and they have also pushed a similar patch[2] which we co-developed. LXC is a bit harder to exploit, but the same fundamental flaw exists.

After some discussion with the systemd-nspawn folks, it appears that they aren't vulnerable (because their method of attaching to a container uses a different method to LXC and runc).

I have been contacted by folks from Apache Mesos who said they were also vulnerable (I believe just using the exploit code that will be provided). It is quite likely that most container runtimes are vulnerable to this flaw, unless they took very strange mitigations before-hand.

== OTHER NEWS ==

We have set up an announcement list for future security vulnerabilities, and you can see the process for joining here[3] (it's based on the Kubernetes security-announce mailing list). Please join if you distribute any container runtimes that depend on runc (or other OCI projects).

[1]: https://github.com/opencontainers/runc/commit/0a8e4117e7f715d5fbeef398405813ce8e88558b [2]: https://github.com/lxc/lxc/commit/6400238d08cdf1ca20d49bafb85f4e224348bf9d [3]: https://github.com/opencontainers/org/blob/master/security.md

-- Aleksa Sarai Senior Software Engineer (Containers) SUSE Linux GmbH <https://www.cyphar.com/>