How to Fix CVE-2023-0386: Linux Kernel OverlayFS Privilege Escalation

Patch immediately. CVE-2023-0386 is a local privilege-escalation flaw in the Linux kernel OverlayFS subsystem. CISA listed it in the Known Exploited Vulnerabilities catalog on 2025-06-17, with a federal remediation due date of 2025-07-08. The fix is to install your distribution's patched kernel and reboot into it. A multi-user or container host with unprivileged users is the most exposed configuration.

What is CVE-2023-0386?

CVE-2023-0386 is a local privilege-escalation vulnerability in the Linux kernel, disclosed on 2023-03-22 and assigned by Red Hat. The bug lives in OverlayFS, the union filesystem that stacks a read-write upper layer on top of a read-only lower layer. OverlayFS is everywhere in modern Linux because it is the default storage driver behind container images on Docker, containerd, and Podman, and it backs many live-CD and immutable-root setups.

The exact wording from the advisory record is this: a flaw was found in the Linux kernel, where unauthorized access to the execution of a setuid file with capabilities was found in the kernel's OverlayFS subsystem in how a user copies a capable file from a nosuid mount into another mount. This uid-mapping bug allows a local user to escalate their privileges on the system.

In plain terms, OverlayFS mishandled the user-namespace uid mapping and the file capabilities attached to an executable when a file was copied up from a lower layer mounted nosuid into the upper layer. An unprivileged user inside a user namespace could craft a binary carrying powerful file capabilities (such as cap_setuid), copy it up through OverlayFS so the capabilities survived into a context where they were honored, and then run it to gain root on the host. The whole chain runs as a normal local user with no special permissions to start with.

This is tracked as CWE-282, Improper Ownership Management. It is an elevation-of-privilege (EoP) flaw, not remote code execution, not a denial of service, and not a memory-corruption bug. The distinction matters for how you prioritize it: an attacker needs a foothold first, then uses this to become root.

Am I affected?

You are affected if you run a Linux kernel whose OverlayFS code predates the fix. The vulnerable code was present in mainline kernels up to and including 6.2-rc6, and the same logic was shipped in the long-term and distribution kernel series that most servers actually run, including the 5.10 and 5.15 lines. The upstream fix is commit 4f11ada10d0a, and every distribution backported it into its own kernel packages, so the version string that matters for you is your distribution kernel build, not the mainline number.

The risk is highest where untrusted users can run code: shared shell servers, CI/CD runners, multi-tenant container hosts, and any box where unprivileged user namespaces are enabled (the default on most modern distributions). A single-user laptop where you are the only account is lower priority, but it still wants the patch because local malware would gain root the same way.

To check what you are running:

# Current running kernel
uname -r

# Full kernel package version and build date (Debian/Ubuntu)
dpkg -l 'linux-image-*' | grep '^ii'

# Full kernel package version (RHEL/Rocky/Alma/Fedora/SUSE)
rpm -q kernel kernel-core 2>/dev/null

# Is the user-namespace attack surface enabled? (1 = enabled)
sysctl kernel.unprivileged_userns_clone 2>/dev/null
cat /proc/sys/user/max_user_namespaces 2>/dev/null

Match the package version against your distribution's security advisory for CVE-2023-0386 (for example Debian DSA-5402, the matching Ubuntu USN, the Red Hat RHSA, or the SUSE advisory). If your installed kernel is older than the fixed build named there, you are vulnerable.

Why this matters

CISA added CVE-2023-0386 to the Known Exploited Vulnerabilities catalog on 2025-06-17 as a Linux Kernel Improper Ownership Management Vulnerability. That listing exists because in-the-wild exploitation was confirmed. Federal civilian agencies were bound by BOD 22-01 to remediate by 2025-07-08, and most enterprises treat the KEV due date as a practical floor for their own change windows.

What makes this one dangerous in practice is that public exploit code has been available since 2023 and the exploit is reliable. It does not depend on a race window you have to win thousands of times; the copy-up path is deterministic. On any host where an attacker already has a low-privileged shell, through a web app compromise, a leaked SSH key, or a malicious CI job, this turns that limited foothold into full root. For container platforms the concern is escape: a process that breaks confinement to the host kernel can use this to own the node.

How to fix CVE-2023-0386

There is one real remediation: run a patched kernel. This is a Linux kernel flaw, so the fix is a kernel package update from your distribution, followed by a reboot into that kernel (or a live patch). There is no application-level setting, no Windows update, and no firewall rule that closes it.

1. Read your distribution's advisory for CVE-2023-0386 (Debian DSA-5402 and the per-distro advisories in References). It names the exact fixed kernel build for each supported release line.
2. Inventory affected hosts first: shell servers, container nodes, CI runners, and any box where untrusted users or workloads execute code.
3. Snapshot or back up critical hosts so you can roll back if the new kernel misbehaves with an out-of-tree module.
4. Install the patched kernel package using your package manager (commands below).
5. Reboot into the new kernel. A kernel fix is not active until the patched kernel is the one running. If you cannot reboot now, use a live-patch service.
6. Verify that the running kernel matches the fixed build, then re-scan.

Patch via your distribution kernel

# Debian / Ubuntu: pull the patched kernel metapackage, then reboot.
sudo apt update
sudo apt install --only-upgrade linux-image-amd64   # Debian
# sudo apt install --only-upgrade linux-image-generic  # Ubuntu
sudo reboot

# RHEL / Rocky / AlmaLinux / Fedora: update the kernel package, then reboot.
sudo dnf upgrade kernel kernel-core
sudo reboot

# openSUSE / SLES: update the kernel-default package, then reboot.
sudo zypper patch     # or: sudo zypper update kernel-default
sudo reboot

If you cannot take an immediate reboot on a production fleet, apply the fix live where your vendor supports it:

# Canonical Livepatch (Ubuntu)
sudo pro enable livepatch
canonical-livepatch status

# kpatch (RHEL family): list and confirm the loaded live patch
sudo kpatch list

# Oracle Ksplice
sudo ksplice -y kernel upgrade

Note: a live patch closes the hole on the running kernel, but you should still reboot into the patched kernel at the next maintenance window so the fix persists across reboots.

Verify the fix landed

# 1. Confirm the running kernel is the patched build (not just installed on disk).
uname -r
dpkg -l 'linux-image-*' | grep '^ii'    # Debian/Ubuntu
rpm -q kernel kernel-core               # RHEL/SUSE family

# 2. Re-scan with your vulnerability scanner (Nessus, Qualys, Tenable, OpenVAS).
#    It should no longer flag CVE-2023-0386 on the patched host.

# 3. Check for kernel errors or a failed boot into the new kernel.
dmesg --level=err,warn | tail -n 40
journalctl -k -b --priority=warning

If you can't patch immediately

If a kernel update is genuinely blocked, reduce the attack surface this specific bug needs. The exploit relies on unprivileged user namespaces, so the most direct hardening is to restrict them:

# Debian/Ubuntu: disable unprivileged user-namespace creation (breaks some
# sandboxes and rootless containers, so test before applying broadly).
sudo sysctl -w kernel.unprivileged_userns_clone=0
echo 'kernel.unprivileged_userns_clone=0' | sudo tee /etc/sysctl.d/99-cve-2023-0386.conf

# Generic limit on user namespaces (RHEL family and others)
sudo sysctl -w user.max_user_namespaces=0

• Restrict who can log in. The bug needs a local foothold, so tighten SSH access, remove dormant accounts, and audit who can run code on shared hosts.
• Lock down container nodes. Enforce non-root containers, drop unneeded capabilities, and keep workloads off nodes that host other tenants.
• Increase monitoring for setuid execution and unexpected root processes spawned from low-privileged sessions.

These steps lower the odds but do not remove the flaw. The patched kernel is the only real fix.

Confirm and recover

1. Confirm uname -r shows the patched kernel build named in your distribution's advisory, and that you have actually rebooted into it.
2. Re-run your vulnerability scanner against the host. CVE-2023-0386 should no longer flag.
3. If you applied the user-namespace hardening as a stopgap, decide whether to keep or revert it once the patched kernel is live, since it can break rootless containers and some browser sandboxes.
4. Because this CVE is exploited in the wild, hunt for prior abuse on any host that ran untrusted code: review auth.log and sudo logs, look for new root-owned setuid binaries, unfamiliar accounts, and unexpected cron or systemd units. Anything anomalous is an incident-response matter, not a passive note.

References

• Upstream kernel fix commit 4f11ada10d0a: git.kernel.org commit 4f11ada10d0a
• Debian advisory DSA-5402: https://www.debian.org/security/2023/dsa-5402
• NetApp advisory: https://security.netapp.com/advisory/ntap-20230420-0004/
• NVD: https://nvd.nist.gov/vuln/detail/CVE-2023-0386
• CISA KEV catalog: https://www.cisa.gov/known-exploited-vulnerabilities-catalog
• CISA KEV entry: "Linux Kernel Improper Ownership Management Vulnerability" - added 2025-06-17

Assembled from the official vendor advisory, NVD record, and CISA KEV listing on 2026-05-25. Always confirm against the vendor advisory before applying changes in production.

Related fixes

Additional nearby issues sensible to fix in the same maintenance window:

• How to Fix CVE-2023-4911: Heap Buffer Overflow in Red Hat Red Hat Enterprise Linux 6
• How to Fix CVE-2023-0266: Use-After-Free in Linux Kernel
• How to Fix CVE-2023-2163: Privilege Escalation in Linux Kernel