The read-only and executable state of a cached file can be separated from its apparent filesystem permissions. A local attacker can overwrite cached content in memory, then run the altered binary to gain root. The failure is not just patch absence, but unsafe trust in kernel fast paths that were never meant to act as privilege boundaries.
What actually breaks in a vulnerable zero-copy path
The failure is not just a bad permission check. A zero-copy path can let the kernel reuse page cache data in a way that no longer matches the file’s intended read-only or executable state, so a process may influence what later readers or executors see without changing the file on disk. In practice, the security boundary shifts from the filesystem object to mutable in-memory cached content.
That matters because many Linux optimisations assume the cache is an implementation detail, not an authority. When that assumption is broken, a local attacker may be able to corrupt cached bytes and then trigger execution of altered code, which turns a performance shortcut into an escalation path.
Why page-cache corruption becomes a privilege problem
Cached file pages are supposed to reflect the trusted contents of a file at the time they are read or executed. If a vulnerable zero-copy path allows writes to the cache or stale aliasing between mappings, the kernel can end up serving attacker-influenced data as if it were the original file. That is especially dangerous for binaries, libraries, and other executable content because the cached page can become the thing the kernel actually runs.
Once execution happens from corrupted cache state, the issue is no longer simple data tampering. It becomes a trust-bypass problem in the kernel’s fast path, where the system treats cached memory as if it still inherits the file’s protection semantics. The result can be local privilege escalation when altered content is executed with elevated rights.
For defenders, the key distinction is between file permissions and runtime integrity. A path can appear read-only on disk and still be unsafe if the kernel allows a separate in-memory representation to diverge from the source of truth.
Where the attack surface usually sits
Zero-copy mechanisms are attractive because they reduce copying between user space and kernel space, but they also reduce the number of places where the kernel revalidates state. When that shortcut is applied to file-backed memory, the risk concentrates around aliasing, cache coherency, and page lifetime rules. If those rules are wrong, a local attacker can exploit the mismatch between what the filesystem says and what the page cache currently contains.
The dangerous pattern is not limited to one syscall family. Any design that depends on the kernel preserving file integrity while reusing cached pages must prove that immutable and executable assumptions still hold after the fast path completes. When it cannot, the attacker does not need to defeat filesystem permissions directly, only the kernel’s trust in its own cached view.
That is why these bugs are often treated as kernel integrity issues first and memory-safety issues second. The kernel is being tricked into authenticating content by location in cache rather than by current file state.
Risk and Threat Considerations
A vulnerable zero-copy page-cache path can convert a local write primitive into code execution or privilege escalation. The exposure is high because the attacker may not need to modify the underlying file, only the cached representation that later execution or reads depend on.
Failure mechanism: The kernel’s fast path reuses cached file pages without preserving the separation between filesystem state and in-memory execution state, so attacker-influenced cache contents can be consumed as trusted file content.
Impact: Integrity of executable content is lost, permissions no longer describe the actual runtime behaviour, and a local attacker may be able to run altered code with elevated privileges.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack surface, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1055 — Process Injection | Local cache corruption can enable arbitrary code execution and privilege escalation. |
| Recommendation — Map execution abuse to ATT&CK technique paths and hunt for local escalation indicators. | ||
| NIST SP 800-53 Rev 5 | SI-7 — Software, Firmware, and Information Integrity | The issue is an integrity failure in trusted executable content and kernel state. |
| Recommendation — Apply SI-7 to verify integrity of executable content and runtime file state. | ||
| ISO/IEC 27001:2022 | A.8.9 — Configuration Management | Kernel fast-path behaviour depends on secure configuration and controlled system behaviour. |
| Recommendation — Control kernel and file-system settings that affect executable content handling. | ||
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | Unsafe kernel fast-path assumptions are a configuration and hardening concern. |
| Recommendation — Harden systems and disable or constrain risky cache-reuse paths where possible. | ||
Practitioner Guidance
What to verify: Treat any zero-copy or cache-reuse path touching executable or security-sensitive files as a candidate trust boundary, not a pure performance optimisation. Verify that the implementation revalidates file state after cache reuse and does not permit writable aliases to persist across execute or read transitions.
Common mistake: Assuming that read-only mounts or normal filesystem permissions are sufficient protection. If the runtime trust model depends on page-cache correctness, you also need to validate kernel behaviour under concurrent access, mapping changes, and cache invalidation.
Practitioner takeaway: When the kernel’s fast path can influence executable bytes, the question is not whether the file is protected on disk, but whether the cached view can ever become a separate authority.
Related resources from NHI Mgmt Group
- What breaks when a Linux kernel logic flaw can write to the page cache?
- What breaks when Linux page-cache corruption is possible on a shared host?
- What breaks when a Linux local exploit can alter the page cache instead of the file on disk?
- What breaks when a Linux host is still running a kernel vulnerable to CVE-2026-53362 after a low-privilege foothold?