CVE-2021-3493

What it actually does

This is a local privilege-escalation flaw in the Linux kernel overlayfs code path as shipped in affected Ubuntu kernels. The kernel failed to correctly validate file capability changes when overlayfs was used together with unprivileged user namespaces and Ubuntu's support for unprivileged overlay mounts. A local user with basic shell access can create an overlay mount, manipulate file capabilities on a file in the underlying filesystem, and execute that file with elevated privileges, resulting in root-level control. The issue has high confidentiality, integrity, and availability impact because successful exploitation gives the attacker full administrative control of the affected host.

Why it matters to the business

Any affected Linux system where an attacker has obtained a low-privileged local account, web shell, compromised service account, or container escape foothold may be converted into full host compromise. This can enable credential theft, tampering with applications and data, disabling security tools, lateral movement, persistence, and service disruption. The vulnerability is listed in CISA KEV, has observed exploitation in the wild, and had a federal remediation deadline of 2022-11-10, so unpatched systems should be treated as high-priority exposure even though exploitation requires local access.

How an attack unfolds

An attacker first needs code execution as a non-root local user on an affected system. That foothold may come from stolen credentials, a compromised application, a web shell, a malicious scheduled job, or another vulnerability. The attacker then checks whether unprivileged user namespaces and overlayfs mounts are permitted. If they are, the attacker creates a user namespace, mounts an overlay filesystem using attacker-controlled lower, upper, work, and merged directories, and abuses the flawed validation of file capabilities to place elevated capabilities on an executable. When the modified executable is run, the kernel incorrectly honors the manipulated capabilities, allowing the attacker to execute commands with root-equivalent privileges. After privilege escalation, the attacker commonly attempts to establish persistence, dump credentials or keys, disable logging or endpoint controls, and use the host as a pivot point.

How to fix it

Upgrade affected kernels to a vendor-fixed version. For source-based tracking, the Linux kernel fix is associated with commit 7c03e2cda4a584cadc398e8f6641ca9988a39d52; for production systems, apply the corresponding distribution kernel package from the operating system vendor rather than only relying on upstream commit status. Reboot systems after kernel updates so the fixed kernel is actually running. If immediate patching is not possible, reduce exposure by disabling unprivileged user namespaces where operationally feasible, restricting unprivileged overlayfs mounts, limiting local shell access, hardening container hosts, and monitoring or blocking suspicious overlay mounts and file capability changes by non-root users. Temporary mitigations may affect container runtimes, sandboxing, build systems, and developer workflows, so test before broad deployment.

How to confirm the fix worked

Confirm both the installed and running kernel are fixed. On Linux systems, compare `uname -r` with the distribution's patched kernel advisory, verify package manager output shows an updated kernel package, and reboot if the running kernel predates the installed fixed package. Validate that affected Ubuntu kernel builds have been replaced by vendor-fixed builds. Where mitigations are used, confirm unprivileged user namespaces are disabled or restricted with `sysctl kernel.unprivileged_userns_clone` where supported, and verify unprivileged users cannot mount overlayfs. Security teams can also run controlled, authorized vulnerability checks from their vulnerability scanner or configuration-management tooling to confirm the host is no longer flagged. Avoid running public exploit code on production systems unless in an isolated, approved validation process.

Typical attack path

1. Obtain low-privileged local code execution on an affected Linux host.
2. Enumerate kernel version, distribution, overlayfs availability, and whether unprivileged user namespaces are enabled.
3. Create temporary overlayfs working directories, commonly under /tmp, /var/tmp, /dev/shm, or another writable location.
4. Enter or create an unprivileged user namespace using tools or syscalls such as unshare/clone.
5. Mount an overlay filesystem with attacker-controlled lowerdir, upperdir, workdir, and merged directory options.
6. Set or manipulate security.capability extended attributes on a chosen executable through the overlayfs path.
7. Execute the modified file to gain root-level privileges.
8. Use root access to add persistence, access secrets, tamper with logs, deploy additional tooling, or move laterally.

How to detect it

Look for signs that a low-privileged user created user namespaces, mounted overlayfs, changed file capabilities, and then spawned a root shell or root-owned process. Useful log sources include auditd syscall logs, Linux auth logs, shell history, EDR process telemetry, container runtime logs, systemd journal, file integrity monitoring, and kernel logs. Hunt for non-root execution of `unshare`, overlay mounts containing `lowerdir=`, `upperdir=`, and `workdir=`, calls to set `security.capability` extended attributes, use of `setcap` in writable directories, and suspicious root shells whose parent process is an unprivileged shell, compiler, script interpreter, or temporary executable. Examine `/tmp`, `/var/tmp`, `/dev/shm`, user home directories, and build workspaces for overlayfs working directories, compiled exploit artifacts, or modified executables with file capabilities. Run `getcap -r / 2>/dev/null` and compare results to a known-good baseline, paying special attention to capabilities on files outside normal system package paths. Also review for post-exploitation activity such as new SSH keys, new privileged users, cron/systemd persistence, disabled security services, cleared logs, or unexpected outbound connections after the suspected privilege escalation time.

• unshare -U
• unshare -Ur
• mount -t overlay
• fstype=overlay
• lowerdir=
• upperdir=
• workdir=
• security.capability
• setcap cap_
• cap_set_file
• setxattr
• /tmp/ovlcap
• /tmp/overlayfs
• /var/tmp/ovlcap
• /dev/shm/ovlcap
• kernel.unprivileged_userns_clone
• overlayfs:
• type=SYSCALL msg=audit
• comm="unshare"
• comm="mount"
• comm="setcap"

What your security team should do

• Immediately identify and patch affected Ubuntu/Linux systems, prioritizing internet-facing servers, container hosts, CI/CD runners, jump hosts, multi-user systems, and systems that process untrusted workloads.
• Treat any unpatched KEV-listed exposure as urgent because exploitation is active in the wild and the CISA remediation deadline has long passed.
• Reboot after kernel updates and verify the fixed kernel is running, not merely installed.
• If patching is delayed, disable or restrict unprivileged user namespaces and unprivileged overlayfs mounts where business operations allow.
• Hunt for suspicious overlayfs mounts, recent file capability changes, and privilege-escalation behavior from low-privileged users.
• Review recent compromises of application accounts, web servers, containers, CI workers, and SSH accounts for possible follow-on local privilege escalation.
• Ensure auditd, EDR, or equivalent telemetry captures mount, unshare/clone namespace creation, setxattr, setcap, execve, and privilege changes on Linux endpoints.
• Investigate unexpected SUID files, files with elevated capabilities, new root-owned files in temporary directories, and changes to persistence locations after suspected exploitation.