Read-only binaries are no longer a reliable trust boundary if the kernel can alter cached pages in memory. Disk checks may still show a clean file while the host executes a modified cached copy as root, so the failure is at runtime integrity, not storage integrity.
What actually breaks when the page cache can be corrupted
The failure is not that the file on disk becomes malicious. The failure is that the kernel may serve a different byte sequence from memory than what the filesystem says is stored, so execution and inspection diverge. On a shared host, that breaks the basic assumption that a clean file path, checksum, or package database reflects the code actually running.
That distinction matters because many trust checks assume storage is the source of truth. Once cached pages can be altered, a read-only binary can behave like an in-memory tampered object even though the underlying image still appears intact.
Why read-only status no longer gives you runtime integrity
Read-only permissions protect the storage path, not the runtime path. If the cache can be altered, the host can execute modified code without changing the file on disk, so an operator looking only at hashes, package manifests, or file metadata can be misled.
This is most severe for shared hosts because one tenant, process, or kernel compromise can affect another workload’s integrity expectations. The practical break is the loss of a reliable boundary between verification and execution, which is why integrity controls have to include memory, provenance, and isolation, not just filesystem permissions.
What defenders should treat as compromised first
The first assumption to drop is that disk-based validation is enough. If the runtime can diverge from storage, then any control that depends on a stable file image, such as post-deployment checksum checks, read-only mounts, or trusted package state, has to be paired with mechanisms that verify the execution environment itself.
On Linux, that means defenders should think in terms of kernel trust, host isolation, and whether the system can prove what was loaded into memory at runtime. If those assurances are weak, the host can still look healthy while serving altered behavior.
Risk and Threat Considerations
When page-cache corruption is possible, the main risk is false trust: teams continue to rely on file integrity signals that no longer describe what is actually executing. That creates a dangerous gap between storage integrity and runtime integrity, especially on multi-tenant or shared systems where blast radius can extend beyond a single process.
Failure mechanism: A kernel-level or cache-level corruption path changes the in-memory pages used for execution, while the on-disk object remains unchanged and passes ordinary verification.
Impact: Administrators may approve or continue running code that is not the code being executed, which can defeat detection, invalidate forensic conclusions, and allow tampering to persist until the cache is rebuilt or the host is restarted.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SI-7 — Software, Firmware, and Information Integrity | Directly addresses runtime and information integrity failures that can bypass file-based trust. |
| CM-6 — Configuration Settings | Shared-host exposure depends on hardened host configuration and trustworthy system state. | |
| SC-39 — Process Isolation | Shared-host cache corruption is an isolation failure across workloads on the same system. | |
| Recommendation — Verify runtime integrity with controls that detect unauthorized code or content changes before execution. Harden host settings so runtime behavior stays consistent with approved configuration baselines. Enforce process isolation to reduce cross-workload impact from host-level corruption. | ||
| NIST CSF 2.0 | PR.DS-08 — Integrity of Data-in-Transit and Data-at-Rest | The scenario breaks integrity assumptions about the stored artifact versus executed content. |
| PR.AA-05 — Network Integrity | Trust boundaries on shared hosts depend on verifying what the system actually executes and serves. | |
| Recommendation — Protect integrity checks with runtime validation, not storage checks alone. Use isolation and verification to preserve trusted execution paths on shared systems. | ||
Practitioner Guidance
What to verify: Treat any claim of integrity on a shared host as incomplete unless you can verify both the stored artifact and the runtime path that feeds execution. If your assurance story stops at file hashes or package checks, it does not answer the page-cache problem.
Decision rule: If the host is shared, privileged, or difficult to attest, prioritize isolation and runtime validation over confidence in read-only binaries. The safer posture is to assume a clean disk image does not guarantee a clean execution image.
Practitioner takeaway: The key judgment is that storage integrity and runtime integrity are different controls, and the latter is the one that fails when the page cache can be corrupted.
Related resources from NHI Mgmt Group
- What breaks when a Linux kernel logic flaw can write to the page cache?
- What breaks when a Linux local exploit can alter the page cache instead of the file on disk?
- Why can file-integrity checks miss page-cache corruption exploits?
- What breaks when a Linux host allows local code execution and an exploitable kernel privilege bug is present?