Detections
Analytics
EulerOS 2.0 SP12 : docker-runc (EulerOS-SA-2026-3331)
medium Nessus Plugin ID 343732
Synopsis
The remote EulerOS host is missing a security update.Description
According to the versions of the docker-runc package installed, the EulerOS installation on the remote host is affected by the following vulnerabilities :['This is a PUBLIC release of a low-severity vulnerability in runc which\nhas been fixed in runc 1.3.6, runc 1.4.3, and runc 1.5.0-rc.3. There was\nNO EMBARGO WINDOW for this vulnerability, as our analysis was that the\nthreat of this issue was not severe and we noticed that a similar issue\nwas publicly fixed in crun[1].\n\nBased on our analysis, this vulnerability has a score of 3.3 (Low) with\na CVSSv3 vector of CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N.\n\n[1]:', '/* Impact */\n\nWhen setting up the container rootfs, setupPtmx and setupDevSymlinks\ncall os.Remove and os.Symlink with a filepath.Join string which allow an\nimage with /dev as a symlink to trick runc into deleting files called\nptmx on the host or creating a hardcoded set of symlinks with specific\nnames and targets in an arbitrary pre-existing host directory.\n\nPlease note that this issue is not exploitable under Docker because it\ncreates a top-level ro layer that masks any malicious /dev symlink\npresent in the container image (this is also done without mounting the\nlower layers so there is no opportunity for the malicious /dev symlink\nto trick it into resolving to some other path). Unfortunately, Podman\nand containerd do not do this and so users using those higher-level\nruntimes with runc can be exploited via a malicious image.\n\nThis issue mirrors a somewhat similar issue in crun, which was also\npublished recently (CVE-2026-47766).\n\n Actually, at the time we analysed this issue, containerd had dead code\nthat implemented this feature but the implementation contained several\nsecurity issues that would arguably have made it more exploitable than\nin runc. Luckily, the code appears to have never been used (at least\nsince 2017) and the code has since been removed[2].\n\n[2]:', '/** Mitigating Factors **/\n\nThere are a few mitigating factors about this issue which reduce the\nimpact for most users quite significantly, and is the reason why we\ndecided to release the fix publicly without an embargo.\n\nWhile the deletion of 'ptmx' seems like a significant issue, in practice\nit is quite limited. Notably, devpts does not permit you to unlink\n/dev/pts/ptmx regardless of privileges and so it is not a usable target\nfor this attack. Additionally, while /dev/ptmx can be unlinked, trying\nto use an image with a symlink from /dev to /dev will cause runc will\nreturn an error before it reaches the buggy code (it correctly detects a\nsymlink loop while setting up the mount target and the code correctly\nscopes the lookup inside the container). Thus, the only files called\nptmx that are guaranteed to exist on the system cannot actually be\nremoved by this bug and so only some user file that happens to have that\nspecific name could be deleted, which seems fairly unlikely to happen on\nreal systems.\n\nAs for the issue of symlinks, again the impact is likely quite limited.\nWhile the creation of arbitrary symlinks could be used to create drop-in\nfiles for system services (and thus lead to a container breakout), the\nhardcoded set of symlink names and targets that this bug allows you to\ncreate on the host make it quite unlikely that you would be able to do\nmuch more than pollute the host system with dummy symlinks. Here is the\ncomplete list of symlinks that can be created with this attack:\n\n * core /proc/kcore\n * fd /proc/self/fd/\n * ptmx pts/ptmx\n * stdin /proc/self/fd/0\n * stdout /proc/self/fd/1\n * stderr /proc/self/fd/2\n\nNote that none of these symlinks are likely to point to user-controlled\ndata -- the /proc/self/fd/$n symlinks are all properties of the process\naccessing them (so privileged processes will only see the state they\nwere spawned with) and the pts/ptmx symlink is almost certainly in the\nsame privilege scope as the directory the symlink itself is in. It seems\nthe only somewhat plausible impact would be that a service could return\nan error when trying to parse one of these symlinks and thus treat it as\nan invalid configuration file. How arbitrary processes deal with this\nsituation is a bit hard to analyse, but most daemons require\nconfiguration files to have certain suffixes (such as .conf) so it\'s not\nreally clear how large the impact is in practice and it seems there are\na few barriers to clear to use this to cause a DoS or other problems.\n\n This would actually be quite problematic if it could occur because\nglibc seemingly only attempts to use /dev/ptmx when creating new\nterminals and thus most terminal managers (including tmux) and shell\ntools (including sudo -- but not su) would fail to start and thus bring\nthe system to a halt.
setupPtmx does add a symlink to /dev/pts/ptmx\nafterwards but on some systems the mode of the host /dev/pts/ptmx is set\nto 0o000 which would still cause the same DoS issue.\n\n/* Mitigations */\n\nUsing user namespaces restricts this attack fairly significantly such\nthat the attacker can only create/delete inodes in directories that the\nremapped root user/group has write access to. Unless the root user is\nremapped to an actual user on the host (such as with rootless containers\nthat don\'t use '/etc/sub[ug]id'), this in practice means that an\nattacker would only be able to create or delete inodes in world-writable\ndirectories.\n\nLSMs can restrict the scope of where in the host filesystem runc can be\ntricked into operating on, though how much this helps is questionable.\nThe default 'container_runtime_t' SELinux label rules (or custom\nAppArmor rules for the host 'runc' context) may restrict the scope where\nthese filesystem operations can operate on, but we have not done an\nin-depth analysis on the impact of those kinds of LSM protections.\n\n/* Patches */\n\nThis issue has been patched in runc 1.3.6, runc 1.4.3, and runc\n1.5.0-rc.3. The patches which resolve this issue on main are:\n\n * 864db8042dbb ('rootfs: make /dev initialisation code fd-based')\n * 66acd48f9d42 ('rootfs: make cgroupv1 subsystem symlinks fd-based')\n\nUnfortunately, backporting them to apply cleanly on top of runc 1.3.5\nand runc 1.4.2 requires quite a few other backports that would bloat the\nset of patches included here. It is almost certainly easier for users to\njust update to the latest patch release (which is our general\nrecommendation for any security release anyway).\n\n/* Credits */\n\nThanks to 'Davias' for initially finding and reporting this issue. The\nsame underlying issue (with varying levels of completeness) was later\nreported by Arthur Chan (@arthurscchan from Ada Logics), Junyi Liu\n(@mosskappa), and Derek Manzella (@Dmanzella).\n\n-- \nAleksa Sarai\nFounding Engineer at Amutable'](CVE-2026-41579)
Tenable has extracted the preceding description block directly from the EulerOS docker-runc security advisory.
Note that Nessus has not tested for this issue but has instead relied only on the application's self-reported version number.
Solution
Update the affected docker-runc packages.See Also
Plugin Details
Severity: Medium
ID: 343732
File Name: EulerOS_SA-2026-3331.nasl
Version: 1.1
Type: Local
Family: Huawei Local Security Checks
Published: 9/8/2026
Updated: 9/8/2026
Supported Sensors: Nessus
Risk Information
VPR
Risk Factor: Low
Score: 3.2
Percentile: 50.78
CVSS v2
Risk Factor: Low
Base Score: 2.1
Temporal Score: 1.6
Vector: CVSS2#AV:L/AC:L/Au:N/C:N/I:P/A:N
CVSS Score Source: CVE-2026-41579
CVSS v3
Risk Factor: Low
Base Score: 3.3
Temporal Score: 2.9
Vector: CVSS:3.0/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N
Temporal Vector: CVSS:3.0/E:U/RL:O/RC:C
CVSS v4
Risk Factor: Medium
Base Score: 4.8
Threat Score: 1.1
Threat Vector: CVSS:4.0/E:U
Vector: CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:P/VC:N/VI:L/VA:N/SC:N/SI:L/SA:N
Vulnerability Information
CPE: cpe:/o:huawei:euleros:2.0, p-cpe:/a:huawei:euleros:docker-runc
Required KB Items: Host/local_checks_enabled, Host/cpu, Host/EulerOS/release, Host/EulerOS/rpm-list, Host/EulerOS/sp
Excluded KB Items: Host/EulerOS/uvp_version
Exploit Ease: No known exploits are available
Patch Publication Date: 9/8/2026
Vulnerability Publication Date: 6/22/2026
Reference Information
CVE: CVE-2026-41579