What Is a Linux Page Cache Attack? How Fragnesia Works

A Linux page cache attack is a privilege escalation technique where a local user changes the in-memory copy of a file they are only allowed to read. The kernel serves that cached copy to every process that opens the file, so a tampered setuid binary or configuration file can hand out root. The file on disk never changes. Fragnesia (CVE-2026-46300), Dirty Frag and Copy Fail are 2026 examples of the same idea, and attackers have now used Fragnesia in the wild.

What is the Linux page cache?

The Linux page cache is the area of RAM where the kernel keeps recently read file contents so the next read does not have to touch the disk. Every normal file read and write on a Linux system passes through it.

When a program opens /usr/bin/su or /etc/pam.d/su, the kernel checks whether the file's pages are already in memory. If they are, it returns them directly. If not, it reads them from disk, stores them in the cache and then returns them. Writes work the same way in reverse: they land in the cache first and are flushed to disk later.

That design is why a busy server shows most of its memory as "cached." It is also why the page cache is a valuable target. Whoever controls a cached page controls what every process on the host sees when it reads that part of the file.

What is a Linux page cache attack?

A Linux page cache attack is any exploit that lets an unprivileged user write into cached pages of a file they should only be able to read. Normal permission checks happen when a file is opened for writing, so a kernel bug that writes into the cache by another route skips them entirely.

The usual targets are files that decide who gets privileges:

• Setuid binaries such as /usr/bin/su. They run as root no matter who starts them. The public Fragnesia proof of concept, like Copy Fail and Dirty Frag before it, corrupts the cached copy of /usr/bin/su.
• Authentication configuration such as PAM files. In the campaign Dream Research documented in October 2026, the attacker changed the cached PAM configuration for su so it granted root without a password.
• Any root-owned script or config that a privileged process reads later.

Once the cached copy is changed, the attacker runs the program or triggers the read, and the kernel does the rest.

How does Fragnesia write into the page cache?

Fragnesia writes into the page cache because the kernel's networking code loses track of which memory belongs to cached files. When TCP receive coalescing merges socket buffers, it drops a marker that says some fragments are shared. The ESP-in-TCP code, part of the kernel's XFRM IPsec framework, then decrypts data in place over those fragments.

The kernel fix is small: it keeps the shared-fragment marker when buffers are coalesced, so ESP makes a private copy before writing. The upstream record lists fixes in stable kernels 5.10.257, 5.15.208, 6.1.174, 6.6.141, 6.12.91, 6.18.33 and 7.0.10. Researchers at Wiz described the result as a "deterministic page-cache corruption primitive," which is what made the public exploit reliable.

Why does a page cache attack evade integrity checks?

A page cache attack evades integrity checks because the modified bytes exist only in memory. The file on disk keeps its original contents, size and timestamps, so a tool that hashes the disk copy reports nothing wrong.

That has three practical consequences:

1. File integrity monitoring can miss it. A tool that reads through the cache may see the tampered bytes, while a tool that compares disk blocks or package checksums offline will not. Do not treat a clean integrity report as proof the host was not exploited.
2. Evidence is volatile. Rebooting the host or dropping the page cache discards the tampered pages. If you suspect exploitation, capture memory before you reboot.
3. The attacker's real foothold is elsewhere. The page cache change is a stepping stone to root. Persistence comes afterwards, through services, scheduled tasks, SSH keys or webshells written to disk with root privileges. Hunt for those.

Why do local bugs like this matter on servers?

Local privilege escalation bugs matter because remote attackers rarely land as root. Web applications, appliance management interfaces and containers usually run as a low-privilege account. A reliable local bug turns that limited foothold into full control.

The Fragnesia campaign followed that pattern exactly. A PHP flaw gave the attacker commands as the nobody user on PAN-OS firewalls, SELinux stopped that user from changing system files, and the kernel bug removed the barrier. CVSS scores the bug at 7.8 with a local attack vector, which understates its value once it is paired with a remote entry point. The full chain is in our report on Fragnesia CVE-2026-46300 and the PAN-OS campaign.

How to reduce your exposure

• Patch and reboot. The fix only applies to the running kernel. Use the Fragnesia fixed kernel versions checklist to confirm each host.
• Remove unused kernel attack surface. Fragnesia, Dirty Frag and Copy Fail all live in kernel features that many servers never use. Blocking the esp4, esp6 and rxrpc modules on hosts that do not run IPsec removes the path.
• Limit who can run code locally. Restrict shell access, keep web and container workloads under confined accounts, and restrict unprivileged user namespaces where your distribution supports it.
• Ask appliance vendors about their kernels. You cannot patch a firewall's kernel yourself. See why appliance Linux kernel patching lags months behind for how to push vendors on it.

For a related set of kernel bugs that reached KEV together, see CISA's September additions of the kTLS, AF_ALG and ebtables flaws.