CVE-2026-64159

What it actually does

This is a Linux kernel netfs logic flaw affecting how the kernel tracks the point in a network-backed file from which unread server data can be assumed to be zero. Under a specific sequence involving local page-cache writes, folio release, and a server-side file size smaller than the local i_size, the kernel may update the zero-point using the local file size instead of the remote server file size. The result is inconsistent read behavior for network filesystems using netfs helpers, observed with CIFS default caching, including short reads or incorrect zero-fill assumptions around EOF. The primary impact is file data correctness and availability rather than code execution or privilege escalation.

Why it matters to the business

Systems that rely on Linux network filesystems for shared application data may experience incorrect reads, failed application I/O, data inconsistency, or workload instability under particular file operation patterns. The issue is not known to be exploited in the wild, is not in CISA KEV, has no reported ransomware use, and has a low EPSS score, so urgency is generally lower than internet-exposed remote code execution flaws; however, organizations with heavy CIFS/SMB or other netfs-backed workloads should still prioritize kernel updates during normal maintenance because silent data inconsistency can affect backups, analytics, databases, build systems, and shared file workflows.

How an attack unfolds

An attacker would need the ability to perform file operations on a vulnerable Linux system against a network-backed filesystem path that uses the affected netfs behavior. The attacker creates or manipulates a file with a crafted sequence of truncates, writes, reads, copy-range operations, and cache interactions so that the local page cache reflects a larger file size than the server-side file size. When affected folios are released, the kernel may incorrectly advance the zero-point based on local i_size rather than remote_i_size. Subsequent reads around the affected region can then return unexpected results, such as short reads at EOF or incorrect zero-filled gaps. This is most plausibly abused to cause application-level data inconsistency or denial of service for processes consuming files from the affected mount, not to gain direct code execution.

How to fix it

Apply a Linux kernel version that includes the upstream fix for the netfs zero-point update logic. Because no product-specific affected or fixed versions were provided, use the fixed kernel packages from the operating system or appliance vendor rather than relying only on upstream version numbers. Prioritize systems that mount CIFS/SMB or other network filesystems using Linux netfs helpers, especially where application correctness depends on sparse files, truncation, copy_file_range, cached reads, or concurrent file modification. If immediate patching is not possible, reduce exposure by limiting write access to network-mounted paths, avoiding high-risk sparse-file/truncate-heavy workloads on affected mounts, disabling or changing client-side caching where operationally acceptable, and monitoring for application I/O anomalies. Reboot into the patched kernel after installation; merely installing kernel packages is insufficient if the running kernel remains vulnerable.

How to confirm the fix worked

Confirm the running kernel, not just the installed package, is updated to a vendor release containing the fix. Validate with `uname -r`, package-manager kernel inventory, and vendor advisories for the relevant distribution. For exposure validation, inventory mounted network filesystems using commands such as `mount`, `findmnt`, and `/proc/mounts`, and identify CIFS/SMB or other netfs-backed mounts with client-side caching enabled. Functional validation can include running filesystem stress/regression tests that exercise truncate, sparse write, read, and copy-range operations on representative network mounts, such as xfstests-style workloads, and confirming there are no short reads or unexpected zero-filled regions around EOF. After reboot, verify applications using network-mounted files no longer report unexplained short reads, EOF errors, or data mismatch conditions.

Typical attack path

1. Obtain local access or application-level write access to files on a vulnerable Linux host using an affected network filesystem mount.
2. Identify a netfs-backed path, such as a CIFS/SMB-mounted share using kernel caching behavior.
3. Create or modify a file using a sequence of truncation, sparse writes, reads, and copy-range operations that makes local i_size exceed the server-side remote_i_size.
4. Trigger page-cache or folio release behavior through memory pressure, cache eviction, file close/reopen, or normal filesystem activity.
5. Cause later reads around the manipulated file offset to observe incorrect EOF, short-read, or zero-fill behavior.
6. Leverage the incorrect file contents or I/O failures to disrupt dependent applications, corrupt processing results, or cause operational failures.

How to detect it

There are no reliable network indicators or kernel log signatures that uniquely identify exploitation of this flaw. Detection should focus on retrospective evidence of abnormal file I/O behavior on Linux systems using network filesystem mounts. Review application logs, job logs, and storage-client logs for short reads, unexpected EOF, checksum mismatches, file validation failures, or inconsistent results involving files on CIFS/SMB or other netfs-backed mounts. Review system logs and kernel logs for filesystem or CIFS-related read errors around the same time, while recognizing that the vulnerable condition may not emit a kernel message. Correlate suspicious events with users or processes performing heavy truncate, sparse write, copy_file_range, mmap/read, or file-stress activity on network-mounted paths. If possible, compare affected files against authoritative server-side copies, backups, checksums, or application-level integrity records to determine whether consumers observed incorrect content. Threat hunting should prioritize multi-user systems, build hosts, data-processing nodes, and application servers where untrusted or semi-trusted users can write to network shares.

What your security team should do

• Inventory Linux systems using CIFS/SMB or other network-backed filesystems and rank those supporting critical applications or shared data workflows highest for remediation.
• Patch affected systems through the OS vendor kernel update channel and reboot into the fixed kernel during the next appropriate maintenance window.
• Treat this as a data-integrity and availability risk: coordinate with application, storage, and platform teams to identify workloads that rely on sparse files, truncation, copy_file_range, or cached network file reads.
• Where patching is delayed, restrict untrusted users and applications from writing to shared network mounts and consider safer cache settings if performance impact is acceptable.
• Review application and system logs for unexplained short reads, EOF-related errors, file checksum mismatches, or data-processing inconsistencies on network-mounted paths since the introduction of vulnerable kernels.
• Because there is no known KEV listing, ransomware association, or public exploit maturity, do not displace emergency remediation for actively exploited internet-facing vulnerabilities, but include this fix in regular kernel patch baselines.