CVE-2023-0386: Linux Kernel Improper Ownership Management Vulnerability

CVE-2023-0386 is an improper ownership management flaw in the Linux kernel’s OverlayFS subsystem. It lets a local user gain elevated privileges by abusing how the kernel handles setuid files that carry capabilities when those files are copied from a nosuid mount into another mount. Because the bug sits in a core filesystem feature used by containers, package managers, and many multi-tenant hosts, successful exploitation can turn an ordinary local account into full system control. Confirm exact impact and fixed versions against the vendor advisory for your distribution.

How it works

The weakness is classified as CWE-282 (Improper Ownership Management). In OverlayFS, a user can copy a file that possesses capabilities from a mount marked nosuid into a different mount. A uid-mapping error in the kernel then allows the copied file to retain or regain setuid-like execution rights that should have been stripped. A local attacker who can create or place such a file therefore obtains unauthorized execution of a privileged binary, escalating from an unprivileged user to root or equivalent capabilities. No remote vector is described; the attacker must already have a local foothold. Exact call sequences and mount combinations must be verified in the vendor advisory rather than assumed from public summaries.

Am I affected? How to find it in your systems

Any system running a Linux kernel that includes the OverlayFS subsystem is potentially in scope. OverlayFS is commonly enabled on container hosts (Docker, Kubernetes, LXC), cloud images, and distributions that use overlay mounts for package layering or user namespaces. Inventory steps:

• Enumerate running kernels with uname -r and package queries (for example, rpm -q kernel or dpkg -l linux-image) and compare them to the fixed versions listed in your distribution’s advisory.
• Check for active OverlayFS mounts: findmnt -t overlay or cat /proc/mounts | grep overlay.
• Look for user-namespace or container runtimes that rely on OverlayFS storage drivers.
• Review audit or kernel logs for unexpected setuid executions, capability changes, or privilege-escalation events after file copies involving overlay mounts. Telemetry that records mount operations and capability grants can surface anomalous activity, though absence of such logs does not prove safety.

Because no specific version range is supplied here, treat every unpatched kernel that supports OverlayFS as suspect until the vendor advisory is checked.

How to remediate

Apply the kernel update supplied by your Linux distribution vendor as soon as it is available. The CISA-required action is to follow the vendor’s mitigation instructions, apply BOD 22-01 guidance where cloud services are involved, or discontinue use of the product if no mitigation exists. After patching:

• Reboot into the new kernel and verify the version.
• Confirm OverlayFS behavior no longer permits the ownership bypass (re-test only in a controlled environment).
• Harden residual risk by restricting unprivileged user namespaces if your workload permits, and by ensuring nosuid mounts remain correctly labeled.

Document the change and retain evidence of the advisory version applied.

If you can't patch immediately

Until the vendor kernel update can be installed, reduce exposure with compensating controls:

• Limit local interactive and service accounts that can create files on OverlayFS mounts; prefer dedicated, non-privileged service users.
• Where feasible, disable or avoid OverlayFS storage drivers for containers and fall back to alternative graph drivers that do not exhibit the same mapping behavior.
• Apply mount options that enforce nosuid, nodev, and noexec on untrusted overlay layers, and keep user namespaces tightly constrained.
• Segment hosts that must retain OverlayFS so that a compromised local account cannot reach high-value assets.
• Increase monitoring for capability grants, setuid executions, and unexpected privilege transitions; alert on any process that obtains CAP_SETUID or CAP_SYS_ADMIN after a file copy involving overlay mounts.
• Virtual patching or LSM rules (SELinux/AppArmor) that deny the specific copy-and-execute pattern can buy time, but they are not a substitute for the kernel fix.

These measures lower likelihood and impact; they do not eliminate the vulnerability.

If your data may have been exposed

Local privilege-escalation flaws of this class are frequently chained after an initial foothold and can lead to full host compromise, credential theft, or lateral movement. Known ransomware use of this specific CVE is not documented, yet any successful escalation still warrants treating the host as potentially breached. Rotate credentials that resided on the system, review access logs for unauthorized activity, and consider a free exposure scan of administrative email addresses against known breach corpora to determine whether related accounts have already appeared in public dumps. Continue monitoring until the kernel is patched and residual indicators are cleared.