CVE-2026-64160

What it actually does

This is a race condition in the Linux kernel netfs library affecting handling of remote file size metadata, specifically remote_i_size and zero_point. These values can be read or updated without the same synchronization guarantees used for i_size, creating a risk of torn reads or writes and corruption of the i_size sequence counter. In affected kernel code paths, inconsistent file size state may cause incorrect read/write decisions, stale or partial size values, data corruption, denial of service through kernel instability, and potentially broader confidentiality or integrity impact if the corrupted state is used to drive unsafe memory or I/O behavior.

Why it matters to the business

Systems running affected Linux kernels and using netfs-based filesystem functionality may be exposed to instability or data integrity risks in file access paths. In practical terms, exploitation could lead to service disruption, corrupted file contents, failed workloads, or unauthorized effects on data handled by network-backed filesystem operations. The issue is not currently listed in CISA KEV, has no reported ransomware association, and has a low EPSS score of 0.00407, which suggests no strong public evidence of widespread exploitation at this time; however, the high CVSS score means exposed or critical Linux systems should still be prioritized for kernel updates during normal security maintenance windows.

How an attack unfolds

An attacker would need to trigger affected netfs file-size update and access paths in a vulnerable Linux kernel. The attacker attempts to create concurrent file operations that cause remote_i_size or zero_point to be read while another path updates related size state without proper locking. If the timing window is hit, the kernel may observe a torn or inconsistent size value, leading to incorrect filesystem behavior. Depending on the surrounding filesystem implementation and workload, this may result in file corruption, disclosure or modification of data, or a kernel crash. Reliable exploitation would likely require precise race timing and knowledge of the affected netfs-backed filesystem behavior; no public exploit maturity is currently reported.

How to fix it

Apply the vendor-provided Linux kernel update that contains the netfs locking and seqcount fix. Because no exact fixed versions were provided in the input, use the security advisory from the relevant Linux distribution or kernel vendor to identify the corrected package for each supported release stream. Where immediate patching is not possible, reduce exposure by limiting untrusted access to network-backed filesystem operations, disabling or avoiding affected netfs-based features where operationally feasible, and ensuring only trusted users or services can trigger heavy concurrent file operations on affected mounts. Reboot into the updated kernel after installation; installing a kernel package alone is not sufficient if the running kernel remains vulnerable.

How to confirm the fix worked

Confirm that the running kernel, not just the installed kernel package, is updated to a vendor release containing the fix. Validate with commands such as uname -a, package-manager queries, and vendor advisory version checks. Review whether netfs-related filesystems are in use by checking mounted filesystems and loaded modules. For source-based validation, confirm the kernel includes the change that synchronizes remote_i_size and zero_point handling with the same seqcount and locking expectations as i_size, including holding i_lock while updating relevant size fields. After remediation, run representative filesystem workloads and monitor for kernel warnings, filesystem errors, crashes, or data-integrity anomalies.

Typical attack path

1. Identify a Linux system running a vulnerable kernel version with netfs-based filesystem functionality in use.
2. Gain the ability to interact with the affected filesystem path or cause remote-backed file operations to occur.
3. Generate concurrent reads, writes, truncates, cache activity, or metadata updates intended to race updates to file-size-related state.
4. Attempt to trigger torn or inconsistent reads of remote_i_size or zero_point.
5. Leverage the resulting inconsistent kernel/filesystem state to cause data corruption, service disruption, or other unintended access effects.

How to detect it

There are no known public, unique exploitation indicators for this issue, and exploitation would resemble abnormal filesystem race behavior rather than a simple network signature. To assess possible prior exploitation, review kernel logs, system journals, crash dumps, and filesystem integrity reports for events involving netfs-backed filesystems, cachefiles, network filesystem activity, unexpected file truncation, file-size inconsistencies, kernel warnings, oopses, BUG messages, lockdep reports, or panics during concurrent read/write/truncate workloads. Useful log sources include journald, dmesg, /var/log/kern.log, /var/log/messages, audit logs for file operations, filesystem-specific logs, crash dump facilities such as kdump/vmcore, and endpoint telemetry showing unusual high-concurrency file access against affected mounts. Because no threat actors or campaigns are currently associated with this CVE, treat detections as behavioral triage indicators rather than definitive compromise evidence.

What your security team should do

• Inventory Linux systems and identify those using kernels in the affected release range, especially systems using netfs-backed or network-backed filesystem functionality.
• Prioritize patching internet-facing, multi-user, file-service, container-host, virtualization-host, and critical workload systems even though current EPSS and exploitation maturity are low.
• Apply the appropriate distribution kernel update and reboot systems into the fixed kernel.
• Restrict untrusted user or remote access to affected filesystem paths until patched.
• Monitor kernel logs for filesystem, netfs, cachefiles, lockdep, warning, oops, BUG, or panic events that correlate with file access activity.
• If unexplained file corruption or kernel instability occurred before patching, perform integrity checks on affected data stores and review historical logs for suspicious concurrent filesystem activity.
• Track vendor advisories for exact fixed package versions and backports because Linux distributions may remediate this issue without using the same upstream kernel version number.