CVE-2026-80899

What it actually does

The Linux kernel EROFS fscache (CacheFiles on-demand) backend contained unresolved implementation defects in the kernel path used for lazy pulling of EROFS images. Maintainers removed the backend entirely rather than continuing to analyze or patch it. Exposure is limited to kernels that still include and use that deprecated on-demand fscache integration (historically isolated by CONFIG_CACHEFILES_ONDEMAND). On those kernels, defects in cache fill and related fscache/netfs handling can disrupt kernel filesystem/cache integrity for EROFS mounts that use the backend, with possible outcomes ranging from incorrect cached content or denial of service to other kernel-level failures. Kernels built without the backend, or that never mount EROFS over fscache, are not affected.

Why it matters to the business

Operational impact is concentrated on stacks that still use EROFS-over-fscache for image lazy pulling (historically some container distribution workflows such as Nydus). Those environments must kernel-update and migrate off the removed path to supported equivalents (file-backed EROFS mounts and fanotify pre-content hooks) or they lose the old lazy-pull method and retain residual risk until they do. Most general-purpose Linux estates that do not enable this backend see little to no business impact. The issue is not in CISA KEV, is not associated with ransomware, and has no public exploit maturity about 25 days after publication, so it does not warrant emergency enterprise-wide interruption unless you actually run the deprecated backend.

How an attack unfolds

There is no public exploit, no named threat actor, and no KEV or ransomware campaign tied to this issue. A realistic attempt would require a target whose running kernel still contains the deprecated EROFS fscache backend and that actually uses it (EROFS mounted with fscache/CacheFiles on-demand lazy pull). The attacker would then try to influence on-demand cache population or related cachefiles operations so the defective backend mishandles a fill or associated kernel caching work. Public write-ups do not fully characterize the underlying defects—maintainers explicitly declined further investigation because the feature had been deprecated for nearly two years—so there is no documented, reliable end-to-end exploit chain. Successful abuse is therefore expected to be uncommon, local to systems still running the old backend, and not a mass-internet threat.

How to fix it

Install a vendor Linux kernel that includes the EROFS fscache backend removal (upstream aimed this at Linux 7.2 and corresponding stable/vendor backports). Do not keep or re-enable the deprecated backend. If you depended on EROFS-over-fscache for lazy pulling (including Nydus fscache mode), migrate to EROFS file-backed mounts and fanotify pre-content hooks, which are the supported replacements and already implemented in erofs-utils. Until you can upgrade, do not enable on-demand CacheFiles/EROFS fscache, and do not mount EROFS with that backend. Use your distribution’s kernel packages rather than ad-hoc cherry-picks unless you maintain a custom kernel tree.

How to confirm the fix worked

Confirm the running kernel changelog or vendor advisory lists the EROFS fscache backend removal. On a patched kernel, the on-demand EROFS fscache path should be gone; kernel config should not present a usable EROFS-over-fscache backend, and /proc/mounts should show no EROFS mounts using fscache. Verify cachefiles on-demand is not required for remaining workloads, and that any former lazy-pull users (for example Nydus) now operate via file-backed EROFS or fanotify pre-content hooks. Reboot into the new kernel and regression-test image pull/mount paths. Unpatched exposure looks like an older kernel still offering EROFS fscache plus an active cachefiles on-demand/fscache-backed EROFS mount.

Typical attack path

1. Find a Linux host whose kernel still includes the deprecated EROFS fscache/on-demand backend.
2. Confirm EROFS is actually mounted with fscache/CacheFiles on-demand (lazy image pull), not a plain local EROFS mount.
3. Place attacker-controlled or attacker-influenced content into the on-demand pull/cache fill path used by that mount.
4. Induce the defective backend to handle a cache fill or related cachefiles/netfs operation.
5. Cause a kernel-level failure in that path (crash, bad cached data, or other backend malfunction), which is only possible while the removed code is still present and in use.

How to detect it

No in-the-wild exploitation, named actors, or exploit artifacts are published, so hunting is primarily for prior use of the vulnerable path rather than a known compromise signature. Review kernel and boot logs for EROFS mounts tied to fscache/cachefiles, cachefilesd/on-demand activity, and Nydus fscache-mode configurations. Kernel oops or panic traces involving erofs together with fscache, netfs, or cachefiles during on-demand fills would be the most relevant crash-class evidence if a defect was triggered. Hosts whose running kernel no longer contains the backend, or that never mounted EROFS over fscache, could not have been exploited via this issue.

What your security team should do

• Inventory hosts for EROFS mounts using fscache/CacheFiles on-demand and for Nydus or similar lazy-pull configurations; patch and migrate those first.
• Apply the vendor kernel that removes the EROFS fscache backend; do not attempt to preserve the deprecated code.
• Migrate remaining lazy-pull workflows to file-backed EROFS mounts and fanotify pre-content hooks before or as you upgrade.
• Disable unused CacheFiles on-demand/fscache configuration on systems that do not need it.
• Treat this as normal kernel-patch cadence unless the deprecated backend is in production: it is not KEV-listed, not ransomware-associated, and has no known exploit 25 days after publication.
• Track distribution stable backports rather than waiting only for a major upstream version bump.