Linux Copy Fail shows how page cache corruption can become root

At a glance

What this is: CVE-2026-31431 is a Linux kernel privilege-escalation flaw that can turn local, unprivileged access into root through page-cache corruption.

Why it matters: It matters because IAM and security teams must treat kernel trust boundaries, runtime exposure, and privilege scope as part of identity risk, not just patch management.

By the numbers:

• The researchers tested exploitation on Ubuntu 24.04 LTS, Amazon Linux 2023, RHEL 14.3, and SUSE 16, across kernel lines 6.12–6.18.

👉 Read Orca Security's analysis of CVE-2026-31431 and Linux root escalation

Context

Copy Fail is a local privilege-escalation vulnerability in the Linux kernel, not a user-space application bug. A low-privilege user can abuse a kernel crypto path to corrupt cached file pages and obtain root, which means the security boundary failed below the level most access reviews and endpoint checks normally observe.

For identity and access programmes, this is a reminder that privileged execution on shared Linux infrastructure is part of the access model. Containers, distribution kernels, and runtime controls can all inherit the same trust failure when a kernel path turns readable content into a writable privilege boundary.

The issue also matters because the disk file itself is left unchanged, so file integrity monitoring may not show the exploit path. That makes runtime reachability and kernel version exposure more relevant than static hashes alone when teams prioritise remediation.

Key questions

Q: What breaks when a Linux kernel vulnerability lets a low-privilege user gain root?

A: The boundary between unprivileged and privileged execution breaks at the kernel level, so controls built around user roles or application isolation no longer describe the real risk. When the exploit corrupts page-cache-backed content, the on-disk file can stay intact while the system state becomes hostile. That is why host-level patching and runtime exposure analysis matter.

Q: Why can file-integrity checks miss page-cache corruption exploits?

A: File-integrity checks usually verify the disk object, but Copy Fail abuses the page cache, which is the in-memory copy the kernel serves at runtime. If the disk file is unchanged, hashes and timestamps may look normal even though privileged code consumed altered cached data. Teams need controls that observe kernel version, runtime reachability, and exploitability.

Q: How do security teams prioritise Linux kernel fixes when multiple distributions are affected?

A: Prioritise by exposed kernel version, reachable attack path, and asset criticality rather than by distribution label alone. A kernel flaw can cross container boundaries and affect several Linux families at once, so the remediation queue should be built from host exposure and business impact, not from the application layer. That avoids false confidence from clean container images.

Q: Who is accountable when a kernel privilege-escalation flaw affects containers and workloads?

A: Accountability usually sits with the team that owns the host platform and its patch cadence, because the shared kernel is the common dependency. Workload teams still need to know whether their runtime is exposed, but the control failure is host-level. That makes platform ownership, remediation SLAs, and exception handling the key governance questions.

Technical breakdown

AF_ALG AEAD in-place decryption creates a writable page-cache path

The vulnerable path arises from the interaction of AF_ALG, splice(), and the authenc(aesn) AEAD template. AF_ALG exposes kernel cryptography to userspace, while splice() can pass page-cache-backed file pages by reference instead of copying them. In the affected in-place decryption flow, those pages are treated as part of a writable scatterlist, so a page that should remain readable-only can be altered through the crypto operation. That is a kernel memory-handling failure, not a file-content change on disk.

Practical implication: block or restrict AF_ALG AEAD usage on exposed systems until patched kernels are deployed.

Why file-integrity checks can miss Copy Fail exploitation

Copy Fail does not need to rewrite the file on disk. The exploit works through the page cache, which is the memory-resident copy the kernel uses to serve readable file content efficiently. Because the on-disk artifact remains unchanged, traditional integrity checks that compare hashes or watch file timestamps may see nothing unusual even while the cached copy is corrupted and used by a privileged process. That is why the attack is harder to spot from a pure file-control viewpoint.

Practical implication: add kernel-version and runtime exposure checks to remediation triage instead of relying only on file-integrity alerts.

Shared page cache expands impact across containers and Linux variants

The researchers reported testing across Ubuntu 24.04 LTS, Amazon Linux 2023, RHEL 14.3, and SUSE 16 on kernel lines 6.12 to 6.18, and noted that containers or other distributions may also be affected because page cache is shared. That means the exploit surface is tied to the kernel lineage and the host, not just to one application image or one container workload. In practice, a vulnerable host can expose multiple workloads that appear isolated at the application layer.

Practical implication: inventory vulnerable host kernels centrally and treat container isolation as insufficient protection from kernel-level abuse.

Threat narrative

Attacker objective: The attacker aims to convert local user access into root on affected Linux systems and then extend control to workloads running on the compromised host.

1. Entry: an unprivileged local user reaches a vulnerable Linux kernel that exposes AF_ALG AEAD in-place processing.
2. Credential_harvested: the attacker does not steal credentials directly but manipulates readable file pages in the page cache to create a privileged execution condition.
3. Escalation: the corrupted cached content is used to gain root on the host, bypassing the expected read-only boundary of the file.
4. Impact: root access enables full host compromise, with downstream risk to containers, workloads, and any data or secrets reachable from the system.

Breaches seen in the wild

• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.
• BeyondTrust API key breach — compromised BeyondTrust API key led to unauthorized SaaS access.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Copy Fail is a kernel trust failure, not just a patchable bug. This vulnerability shows that identity and privilege boundaries can collapse below the application layer when the operating system itself turns readable content into a writable execution path. Access governance that stops at users, roles, or container policies misses the fact that root can emerge from a kernel data path. Practitioners should treat kernel exposure as part of privilege governance, not merely infrastructure hygiene.

The named failure mode here is page-cache write-through from a read-only file path. That is the specific premise that broke: readable files were assumed to stay immutable in memory, even while the AF_ALG AEAD in-place path allowed cached pages to participate in writable operations. This matters because it explains why normal integrity controls may not flag compromise. Practitioners need to recognise that a file can remain unchanged on disk while its cached execution context becomes hostile.

Containers inherit host kernel identity risk whether or not their images are clean. The article’s container relevance is a reminder that workload isolation does not sever the shared kernel trust base. A workload identity model that assumes image provenance or namespace boundaries are enough will fail when the host kernel is the weak point. The implication is clear: runtime authority must be evaluated at the host kernel layer, not only at the workload layer.

Linux privilege escalation must now be analysed as an identity lifecycle problem for hosts. A vulnerable kernel creates a lifecycle gap between patch availability, exposure duration, and the point at which a low-privilege session becomes root. That gap is measurable, operational, and exploitable. Practitioners should interpret kernel hardening as part of access governance for non-human execution environments, not as an isolated vulnerability management task.

Page-cache corruption is a named concept worth tracking in NHI governance. It describes a class of failure where the authority to execute or elevate does not come from a credential alone, but from corrupting the memory-resident representation of trusted content. That shifts attention from secret theft to trust-anchor corruption. Security teams should account for kernel-mediated privilege conversion when modelling blast radius on Linux hosts.

From our research:

• The researchers tested exploitation on Ubuntu 24.04 LTS, Amazon Linux 2023, RHEL 14.3, and SUSE 16, across kernel lines 6.12–6.18, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
• Another finding from the same research shows that when AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, and as quickly as 9 minutes in some cases.
• That speed of exploitation reinforces why teams should study The 52 NHI breaches Report for patterns in exposed access, rapid abuse, and host-to-workload blast radius.

What this signals

Linux kernel exposure now belongs in the same risk conversation as privileged identity scope, because a shared host kernel can turn an apparently narrow local flaw into root across multiple workloads. Teams that still separate platform patching from access governance will miss the point of incidents like Copy Fail.

Host kernel authority: when the operating system is the privilege boundary, container isolation and file-integrity checks are not enough to define risk. Security programmes should map vulnerable kernels to runtime-critical workloads and then use that mapping to drive remediation priority.

For practitioners, the practical shift is toward host-centric exposure management. Pair platform inventory with patch state, runtime reachability, and critical workload mapping, then anchor policy decisions in kernel risk rather than treating it as a separate infrastructure ticket.

For practitioners

• Patch vulnerable kernels immediately Prioritise host images and live systems running kernel lines in the affected range, then validate the fix on the actual distribution build rather than the package name alone.
• Block AF_ALG AEAD where it is not required Use blacklisting for algif_aead or equivalent policy controls to disable the vulnerable crypto path on systems that do not need kernel crypto socket access.
• Triage by runtime reachability, not just CVSS Rank exposed systems by whether the kernel path is reachable in their current runtime context, and include internet exposure and asset criticality in the decision.
• Treat shared-host containers as kernel-shared assets Assume any container on a vulnerable host inherits the same kernel attack surface, and group remediation by host kernel rather than by image inventory.

Key takeaways

• Copy Fail shows that a Linux kernel can convert read-only file access into root without modifying the disk object, which breaks the assumptions behind standard integrity checks.
• The vulnerability was tested across multiple major distributions and kernel lines, so teams should treat host kernel exposure as a shared workload risk rather than a single-platform issue.
• Patching, AF_ALG restriction, and runtime exposure review are the controls that directly reduce this specific privilege-escalation path.

Key terms

• Page Cache Corruption: Page cache corruption is a runtime failure where memory-resident file pages are altered even though the file on disk remains unchanged. In Linux, that matters because privileged code may consume the cached data while integrity tooling still sees a clean disk object.
• AF_ALG: AF_ALG is a Linux kernel interface that exposes cryptographic algorithms to userspace. When it is used in vulnerable paths, it can become part of a privilege-escalation chain rather than a simple service interface, especially when kernel memory handling is unsafe.
• Privilege Escalation: Privilege escalation is the act of moving from a lower permission level to a higher one, such as from an unprivileged local user to root. In Linux host governance, it is a control failure that can invalidate workload isolation and expand blast radius quickly.

Deepen your knowledge

Linux kernel privilege-escalation response and host exposure triage are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building a governance model for shared Linux hosts and containerised workloads, it is worth exploring.

This post draws on content published by Orca Security: Linux kernel vulnerability CVE-2026-31431, Copy Fail. Read the original.