CVE-2026-80897

What it actually does

Reference leak in netfs_prepare_read_iterator() where batched readahead folios remain held if rolling_buffer_load_from_ra() fails after put_batch, preventing proper release of memory references on the error path.

Why it matters to the business

Gradual kernel memory exhaustion on Linux systems performing netfs readahead operations can lead to performance degradation, resource contention, or system instability over time.

How an attack unfolds

An attacker triggers filesystem read operations that exercise the netfs readahead path, induces a failure in rolling_buffer_load_from_ra after folio batching has occurred, and repeats the sequence to accumulate unreleased references without triggering known remote code execution.

How to fix it

Apply the upstream kernel patch that adds batch release before returning the error from netfs_prepare_read_iterator(); rebuild and deploy updated kernels across affected systems.

How to confirm the fix worked

Review netfs read iterator preparation code for explicit batch cleanup on all error paths from rolling_buffer_load_from_ra; confirm memory accounting stabilizes under repeated readahead error injection.

Typical attack path

1. Initiate netfs-backed file read or readahead workload
2. Force error condition in rolling_buffer_load_from_ra after initial folio batching
3. Repeat error-triggering sequence to accumulate unreleased folio references
4. Monitor for kernel memory pressure or OOM conditions

How to detect it

Correlate high kernel memory usage or slab growth with netfs or filesystem readahead activity in dmesg, /proc/meminfo, and slabtop output; inspect for repeated error paths in netfs iterator code under load.

What your security team should do

• Prioritize kernel updates containing the netfs batch-release fix once released
• Monitor kernel memory usage and slab statistics for netfs-related growth
• Limit exposure by restricting untrusted filesystem mounts that use netfs readahead