CVE-2026-53393

What it actually does

This is a Linux kernel NFS server (nfsd) data-integrity flaw. When deferred writeback fails after an NFS client has sent UNSTABLE write data, nfsd detects the writeback error but does not rotate the NFS write verifier before returning the error path. Because the verifier remains unchanged, a client can later issue COMMIT, receive the same verifier, and incorrectly conclude that its previously written data reached durable storage. The result is silent data loss or file corruption from the client’s perspective, rather than a clear retry/rewrite signal. This is not a typical code-execution or privilege-escalation vulnerability; the primary impact is integrity and durability failure under writeback-error conditions.

Why it matters to the business

Organizations using Linux systems as NFS servers could experience silent loss or corruption of files when backend storage reports deferred write failures. The risk is most serious for shared file services, build systems, research data stores, backup targets, application shared storage, and any workflow that assumes NFS COMMIT confirms durable persistence. EPSS is currently very low and there is no known KEV listing or ransomware association, so broad active exploitation is not indicated; however, the operational consequence can be severe because affected clients may believe data was safely saved when it was not.

How an attack unfolds

An attacker would need access to write to an affected Linux NFS export and would also need conditions that cause deferred writeback errors on the server, such as storage I/O failures, full or failing backing devices, filesystem errors, quota-like exhaustion, or deliberately induced backend instability where the attacker has influence over storage pressure. The attacker writes data using NFS semantics that allow UNSTABLE writes, then relies on the server hitting a deferred writeback failure. Because the vulnerable nfsd path does not reset the write verifier, the client’s later COMMIT can receive the unchanged verifier and treat the data as durable. In a malicious scenario, this could be used to create targeted data inconsistency or denial of integrity; in many real-world cases, the same issue may be triggered accidentally by storage faults rather than by a human adversary.

How to fix it

Apply a Linux kernel update from the relevant distribution or kernel vendor that includes the nfsd fix to reset the write verifier on deferred writeback errors in both nfsd_vfs_write() and nfsd_commit(). No product-specific fixed versions were provided in the input, so use vendor advisories and package changelogs to identify the first fixed kernel for each distribution. Prioritize NFS servers that host critical shared data or have a history of storage/writeback errors. Until fixed kernels are deployed, reduce exposure by improving backend storage reliability, investigating and eliminating writeback/I/O errors, avoiding overloaded or nearly full filesystems, maintaining tested backups, and considering stricter synchronous-write export behavior where operationally acceptable. Mitigations reduce the likelihood or impact of the bug but do not correct the protocol-state error; kernel patching is the durable fix.

How to confirm the fix worked

Confirm the running kernel is a vendor-fixed build, not merely that an updated package is installed and pending reboot. Validate with package manager metadata, distribution security advisories, kernel changelogs, or source/patch inspection showing the nfsd write-verifier reset was added around filemap_check_wb_err() error handling. On systems built from source, confirm the nfsd code calls commit_reset_write_verifier() on the relevant deferred writeback-error paths. In a controlled lab, a regression test can induce writeback failure during NFS UNSTABLE write and COMMIT flows and verify that the server changes the write verifier so clients are forced to retransmit data. Do not perform destructive writeback-failure testing on production storage.

Typical attack path

1. Gain legitimate or compromised write access to an NFS export served by an affected Linux kernel.
2. Generate or wait for NFS writes that are handled as UNSTABLE data requiring a later COMMIT.
3. Create, amplify, or coincide with backend storage conditions that cause deferred writeback errors on the NFS server.
4. Allow the client to issue NFS COMMIT for the previously written data.
5. The vulnerable server returns the unchanged write verifier instead of rotating it after the writeback error.
6. The client assumes the data is durable and does not resend it, resulting in silent data loss or corruption.

How to detect it

This issue does not leave a reliable exploit-specific signature, and absence of logs does not prove absence of impact. Detection should focus on identifying affected NFS servers and time windows where deferred writeback or storage failures occurred while clients were actively writing through NFS. Review kernel logs, system journal, syslog, storage-controller logs, filesystem logs, and NFS server telemetry for writeback errors, I/O errors, filesystem aborts, remount-read-only events, full filesystems, device resets, or nfsd write/commit failures. Correlate those events with NFS client write activity, application error reports, checksum mismatches, unexpected file truncation, missing output files, or backup verification failures. If storage-error windows are found, treat files written through affected NFS exports during those windows as potentially suspect and validate them from application-level checksums, snapshots, backups, or source-of-truth systems.

• nfsd
• writeback error
• I/O error
• Buffer I/O error
• blk_update_request: I/O error
• EXT4-fs error
• XFS: metadata I/O error
• Remounting filesystem read-only
• No space left on device
• filemap_check_wb_err
• COMMIT

What your security team should do

• Inventory Linux NFS servers, especially those serving business-critical shared files, backup repositories, application data, build artifacts, or research datasets.
• Prioritize kernel updates for NFS servers with prior storage, filesystem, or writeback errors, even though public exploitation likelihood is currently low.
• Review distribution advisories for the fixed kernel version and ensure affected systems are rebooted into the patched kernel.
• Search recent server logs for storage writeback, filesystem, block-device, and nfsd errors that could indicate periods where silent data loss was possible.
• For high-value NFS shares, coordinate with application owners to verify data integrity for files written during known storage-error windows.
• Ensure backups, snapshots, or replication copies are recoverable and not solely dependent on potentially corrupted NFS write activity.
• Monitor EPSS, vendor advisories, and kernel stable backports for changes in exploitability or fixed-version availability.