CVE-2026-68448: Linux Kernel Privilege Escalation Flaw

CVE-2026-68448 Overview

CVE-2026-68448 is a Linux kernel vulnerability in the overlayfs (ovl) subsystem. The flaw affects the copy_file_range() operation when files reside on two different overlayfs mounts sharing the same base filesystem. The kernel performed the source file read permission check using the destination overlayfs mounter credentials rather than the source overlayfs mounter credentials. This credential mismatch could grant read access to a source file that would otherwise be denied. The Linux kernel maintainers resolved the issue by explicitly verifying read access to the source file with the source overlayfs mounter credentials.

Critical Impact
Local users can potentially read file contents across overlayfs mounts that access control policy would normally prohibit, resulting in unauthorized information disclosure.

Affected Products

Linux kernel versions containing commit 5dae222a5ff0c ("vfs: allow copy_file_range to copy across devices") and later, prior to the fix
Overlayfs (ovl) filesystem subsystem
Distributions shipping affected kernel builds with overlayfs enabled

Discovery Timeline

2026-08-12 - CVE CVE-2026-68448 published to NVD
2026-08-12 - Last updated in NVD database

Technical Details for CVE-2026-68448

Vulnerability Analysis

The vulnerability resides in the overlayfs implementation of the copy_file_range() file operation. Commit 5dae222a5ff0c allowed filesystems implementing copy_file_range() to opt into cross-superblock copies within the same filesystem type. Overlayfs supports cross-superblock copy when the two underlying real files live on the same base filesystem.

When a cross-superblock copy occurs between two distinct overlayfs mounts, the underlying operation executes with the mounter credentials of the destination overlayfs. The source file's read permission access hook was invoked with those same destination credentials rather than the credentials of the source overlayfs mounter. This credential substitution breaks the access control model that overlayfs enforces at mount time.

Root Cause

The root cause is an incorrect credential context during the ->copy_file_range() path in overlayfs. Overlayfs performs privileged operations on real underlying files using stored mounter credentials. The source file access check reused the destination mounter credentials, bypassing the permission decision that should have been made under the source mounter identity. This is a broken access control condition rather than a memory safety issue.

Attack Vector

Exploitation requires local access with the ability to invoke copy_file_range() between two overlayfs mounts whose lower or upper layers share the same base filesystem. An unprivileged local user who controls the destination overlayfs (or whose destination mounter holds broader permissions than the source mounter) can trigger a copy from a source file. If the destination mounter has read access to the underlying source file but the source mounter does not, the copy proceeds and returns file contents to the caller. This produces an unauthorized read primitive across mount boundaries. The reverse condition can also incorrectly deny legitimate copies, though userspace can fall back to a regular read/write copy loop.

No verified public exploit is available. Technical details are documented in the upstream fix commits referenced by the kernel maintainers.

Detection Methods for CVE-2026-68448

Indicators of Compromise

Unexpected copy_file_range syscalls between file descriptors residing on distinct overlayfs mounts on the same host
Audit records showing successful reads of files whose DAC or LSM policy should have denied the invoking user
Container or sandbox workloads accessing files outside their intended overlayfs layer

Detection Strategies

Enable Linux audit rules on the copy_file_range syscall and correlate source and destination mount points using /proc/self/mountinfo lookups
Monitor for processes that hold file descriptors on multiple overlayfs superblocks concurrently, which is uncommon outside of container runtimes
Compare the effective user of the calling process against the mounter recorded for each overlayfs instance to flag credential mismatches

Monitoring Recommendations

Ingest kernel audit and syscall telemetry into a centralized analytics pipeline for cross-host correlation
Alert on anomalous access to sensitive paths (for example, secrets directories, service account tokens) sourced through copy_file_range in container hosts
Track kernel version and patch level across the fleet to identify hosts still exposed to CVE-2026-68448

How to Mitigate CVE-2026-68448

Immediate Actions Required

Inventory Linux hosts running kernels with overlayfs enabled, prioritizing container hosts, Kubernetes nodes, and CI runners
Apply the upstream kernel patches or the corresponding distribution security update as soon as vendor builds are available
Restrict the ability of unprivileged users to create user namespaces and overlayfs mounts where operationally acceptable

Patch Information

The fix explicitly verifies read access to the source file using the source overlayfs mounter credentials during copy_file_range(). The change is contained in the following upstream commits: Kernel Git Commit 1f4a107, Kernel Git Commit 9ec22c8, and Kernel Git Commit a1e0eb8. Rebuild or upgrade to a kernel that includes these commits, then reboot affected systems.

Workarounds

Disable user namespace creation for unprivileged users via sysctl kernel.unprivileged_userns_clone=0 on distributions that expose this control
Avoid stacking multiple overlayfs mounts backed by the same base filesystem when the mounter identities differ in their access rights
Enforce mandatory access control policies (SELinux, AppArmor) that constrain which files each container or workload may read, reducing the impact of an unauthorized copy

bash

# Verify running kernel and overlayfs usage
uname -r
grep overlay /proc/filesystems
awk '$3 == "overlay"' /proc/self/mountinfo

# Restrict unprivileged user namespaces (Debian/Ubuntu)
sysctl -w kernel.unprivileged_userns_clone=0
echo 'kernel.unprivileged_userns_clone=0' > /etc/sysctl.d/99-userns.conf