CVE-2018-18955

What it actually does

map_write() in kernel/user_namespace.c mishandles ID transformations for nested user namespaces containing more than five UID or GID ranges, allowing a process with CAP_SYS_ADMIN inside the namespace to obtain unauthorized access to host resources such as /etc/shadow.

Why it matters to the business

Attackers can obtain root-level control of affected Linux systems, enabling theft of credentials, installation of persistent malware, and lateral movement; the vulnerability has been public and weaponized for years, so unpatched hosts represent a known, high-value target.

How an attack unfolds

An attacker first creates a user namespace with more than five UID/GID mappings, obtains CAP_SYS_ADMIN inside that namespace, then invokes map_write() so that the faulty kernel-to-namespaced ID conversion maps host credentials back into the namespace, bypassing isolation and granting access to files outside the namespace such as /etc/shadow.

How to fix it

Upgrade the Linux kernel to a version containing commit d2f007dbe7e4c9583eea6eb04d60001e85c6f1bd (or equivalent backport) so that 4.19.2 or later is running; rebuild and reboot with the patched kernel.

How to confirm the fix worked

Confirm the running kernel reports version 4.19.2 or newer, or verify the presence of commit d2f007dbe7e4c9583eea6eb04d60001e85c6f1bd in the kernel source tree; test that namespace ID mappings no longer permit bypass of host access controls.

Typical attack path

1. Create a nested user namespace containing more than five UID or GID ranges
2. Acquire CAP_SYS_ADMIN inside the namespace
3. Invoke map_write() to trigger the incorrect ID mapping
4. Read or write host resources outside the namespace (for example /etc/shadow)
5. Escalate to full root privileges on the host system

How to detect it

Search kernel audit logs and syslog for creation of user namespaces with more than five mappings followed by unexpected access attempts to host files such as /etc/shadow; examine process trees for processes that suddenly gain root after namespace operations.

• map_write.*user_namespace
• CAP_SYS_ADMIN.*user_namespace.*>5
• unexpected open of /etc/shadow from within user namespace

What your security team should do

• Apply the kernel update containing the referenced commit immediately on all affected hosts
• Disable or restrict user namespaces for untrusted users where operationally feasible
• Audit workloads that rely on nested user namespaces with multiple UID/GID mappings
• Monitor kernel logs and process creation for anomalous namespace setup after patching