CVE-2026-46054

What it actually does

This is a local SELinux authorization bypass in the Linux kernel’s overlayfs handling. For files accessed through overlayfs, SELinux is intended to check both the visible overlay file and the underlying backing file, using the current task’s credentials for the user-visible file and the mounter’s credentials for the lower backing file. The vulnerable code failed to enforce the required backing-file SELinux checks during mmap() and mprotect() operations. A local authenticated user or process that can interact with affected overlayfs mounts may obtain memory mappings or change memory protections in ways SELinux policy should have blocked, potentially allowing unauthorized read access to protected backing-file contents or unauthorized executable/writable mappings that undermine SELinux confinement.

Why it matters to the business

Systems that rely on SELinux and overlayfs for workload isolation, container confinement, or multi-user separation may not enforce intended access boundaries. The practical impact is elevated risk that a local user, compromised service account, or containerized workload can access or manipulate data or executable mappings that policy was meant to protect. This is not known to be exploited in the wild, is not in CISA KEV, has low EPSS, and requires local privileges, but it is important for Linux servers, container hosts, and hardened SELinux deployments because it weakens a core access-control layer.

How an attack unfolds

An attacker first obtains local code execution as a non-root user or within a constrained workload on a Linux system using SELinux and overlayfs. The attacker identifies or creates an overlayfs mount where the visible overlay file is accessible but the lower backing file should remain restricted by SELinux policy. Instead of using ordinary file operations that would trigger expected access checks, the attacker uses mmap() to map the overlayfs file into memory or mprotect() to change permissions on an existing mapping. Because the vulnerable kernel path does not fully enforce SELinux checks against the backing file for these operations, the attacker may read protected content or create memory permissions that the policy should deny. Successful exploitation depends on local access, SELinux policy boundaries, overlayfs configuration, and whether the attacker can reach relevant overlay-backed files.

How to fix it

Apply the Linux kernel update from the relevant distribution or kernel vendor that includes the SELinux overlayfs mmap()/mprotect() access-check fix. No universal fixed version was provided, so remediation should be based on vendor advisories and package changelogs for the running kernel branch. Prioritize systems where SELinux is enforcing and overlayfs is used for containers, sandboxing, build systems, or multi-user workloads. If immediate patching is not possible, reduce exposure by limiting local shell access, restricting who can create or use overlayfs mounts, disabling or constraining unprivileged user namespaces where operationally feasible, minimizing privileged container usage, and isolating untrusted workloads from SELinux-sensitive hosts. Do not treat SELinux policy changes alone as a complete mitigation, because the flaw is in kernel enforcement for specific overlayfs memory operations.

How to confirm the fix worked

Confirm the running kernel package has been updated to a vendor-fixed build by checking the installed kernel version, package changelog, and vendor security advisory for this issue. Reboot into the fixed kernel where required; installing a kernel package without rebooting does not remove exposure from the running kernel. Validate SELinux is still enforcing with getenforce or sestatus, and confirm overlayfs usage through mount, findmnt, or /proc/self/mountinfo. For higher-assurance validation, use a controlled test case that attempts mmap() and mprotect() access through overlayfs to a backing file that SELinux policy should deny; after the fix, the operation should be denied consistently with direct backing-file access. Also verify container hosts and build nodes are running the fixed kernel, not merely updated user-space packages.

Typical attack path

1. Gain local authenticated access to an affected Linux system or compromise a local workload running on it.
2. Confirm SELinux is enabled and overlayfs is in use, commonly on container hosts or systems using layered filesystems.
3. Identify an overlayfs file where access to the visible upper layer is permitted but access to the lower backing file should be restricted by SELinux policy.
4. Invoke mmap() on the overlayfs file or use mprotect() to change memory protections on a mapping.
5. Leverage the missing backing-file SELinux enforcement to access data or executable mappings that should have been denied.
6. Use the bypassed access to read sensitive content, weaken confinement, or support further local privilege or lateral movement activity.

How to detect it

There is no reliable single log entry that proves exploitation because the vulnerable behavior is an omitted SELinux enforcement check and may not generate an AVC denial. Detection should focus on suspicious preconditions and follow-on activity. Review auditd, SELinux audit logs, kernel logs, container runtime logs, and shell/process telemetry for unexpected overlayfs mounts, access to overlay-backed files by confined domains, mmap or mprotect activity against files under overlay mount paths, and privilege-escalation or confinement-breakout behavior after such access. On container hosts, correlate container start events, mount creation, user namespace activity, and file access to overlay lowerdir/upperdir/workdir paths. Look for accesses that would normally be inconsistent with SELinux policy boundaries, especially where the same subject would be denied when accessing the backing file directly. Because no public exploitation or named threat actor activity is reported for this issue, detections should be behavioral rather than signature-only.

What your security team should do

• Inventory Linux systems using SELinux and overlayfs, especially container hosts, CI/build workers, shared development systems, and multi-user servers.
• Patch affected kernels using distribution-supported updates and reboot systems into the fixed kernel as a priority for SELinux-enforcing and container-heavy environments.
• Where patching is delayed, restrict local interactive access and prevent untrusted users or workloads from creating overlayfs mounts.
• Review container runtime, user namespace, and mount policies to reduce opportunities for untrusted processes to interact with sensitive overlay-backed files.
• Enable or review auditd and SELinux audit logging for unusual overlayfs access patterns, mmap/mprotect activity, and unexpected mount creation by non-administrative users.
• Treat successful exploitation as a local policy-bypass event: investigate accessed files, affected processes, container boundaries, and any follow-on privilege-escalation behavior.
• Track vendor advisories for exact fixed kernel package versions because no single upstream fixed version applies uniformly across distributions.