CVE-2026-80898

What it actually does

The Linux kernel netfs helper marks a folio PG_private_2 in netfs_pgpriv2_copy_to_cache() before appending it to the copy-to-cache rolling buffer. If that append fails, the folio is never queued for cache writeback, but the flag and its folio reference were not released. The page cache then holds an unreclaimable, incorrectly private folio. Later reclaim, truncation, or writeback can double-put or free the folio while it is still referenced, producing kernel memory corruption (use-after-free / bad page state) in netfs, fscache, and cachefiles paths.

Why it matters to the business

Hosts that use cached Linux network filesystems can leak memory, hang, or kernel-panic, taking down file access and any services on the machine. Kernel memory corruption also creates a local privilege-escalation risk and full host compromise if an attacker already has a foothold. The issue is not in CISA KEV, has no known public exploit, and is about 25 days old, so treat it as standard kernel patching with faster rollout for multi-tenant, container, and cached-NAS fleets.

How an attack unfolds

No public exploit, named threat actor, or ransomware use is associated with this defect. Exploitation would be local: an attacker who can use a netfs-backed filesystem with copy-to-cache enabled causes data to be copied into the local cache, then forces the rolling-buffer append to fail so PG_private_2 stays set on a folio that is never written back. Later page-cache activity on that folio corrupts kernel memory. Outcomes range from denial of service (oops/panic) to, in a skilled local attack, privilege escalation. Remote unauthenticated exploitation is not indicated.

How to fix it

Install the Linux distribution or vendor kernel update that includes the netfs fix to clear PG_private_2 and drop the folio reference immediately when copy-to-cache append fails, then reboot. Exact package versions were not supplied with this record; use your vendor changelog to identify the patched kernel. If patching is delayed and local caching is not required, disable fscache/cachefiles (do not load cachefiles, do not attach a cache, or mount the network filesystem with caching off) so the vulnerable copy-to-cache path is not used. There is no userspace application workaround.

How to confirm the fix worked

Confirm the running kernel package changelog or source includes the netfs change that releases PG_private_2 on copy-to-cache append failure, then reboot and verify uname -r matches that package. Inventory mounts and modules for CIFS/SMB, Ceph, AFS, 9p, fscache, and cachefiles. After patching, watch for recurrence of netfs-related oopses, folio refcount warnings, or 'bad page state' dumps under cached network-filesystem load.

Typical attack path

1. Obtain local access on a host running an affected kernel with a netfs client (for example CIFS/SMB, Ceph, AFS, or 9p) and fscache/cachefiles copy-to-cache enabled.
2. Cause the kernel to copy file folios into the local cache so netfs_pgpriv2_copy_to_cache() runs.
3. Force the copy-to-cache rolling-buffer append to fail so the folio keeps PG_private_2 without being queued for writeback.
4. Induce reclaim, truncation, or writeback on the inconsistently marked folio to trigger kernel memory corruption.
5. Use the resulting instability for denial of service or attempt to turn the corruption into local privilege escalation.

How to detect it

This bug leaves kernel crash artifacts, not malware files or network beacons. Search dmesg, journalctl -k, /var/log/kern.log, and kdump/vmcore around panics for netfs, cachefiles, fscache, PG_private_2, folio/page refcount warnings, and oops stacks mentioning netfs_pgpriv2_copy_to_cache or netfs_pgpriv2_copy_folio. Correlate with use of cached network filesystems. There is no known exploit kit, so unique dropped binaries or C2 indicators are not expected. Missing logs do not prove the path was never hit if the host panicked without persistent logging.

• netfs_pgpriv2_copy_to_cache
• netfs_pgpriv2_copy_folio
• page dumped because: bad page state
• PG_private_2

What your security team should do

• Patch kernels first on hosts that mount netfs clients with fscache/cachefiles, especially multi-tenant and container workers.
• Roll the fix through the rest of the Linux fleet in normal kernel cadence; this is not KEV and has no known in-the-wild exploit.
• If updates will lag, disable local network-filesystem caching where operations allow.
• Hunt kernel logs for netfs/cachefiles oopses and bad page state around crashes; capture vmcore if a node panics.
• Do not prioritize this as an internet-facing remote worm; treat it as local stability and privilege-escalation exposure.