CVE-2026-98267

What it actually does

v9fs_issue_write() fails to recalculate and apply the new minimum file size to i_size and remote_i_size when a write extends the server file, using only start fpos plus the count returned by p9_client_write().

Why it matters to the business

Organizations relying on 9P filesystems for networked or virtual-machine storage face silent file-size drift that can produce data corruption, truncated views of recent writes, or inconsistent behavior across clients.

How an attack unfolds

An attacker writes data beyond the current end-of-file on a 9P mount; the client records a short or zero length increase, leaving local and remote size metadata stale and allowing subsequent operations to operate on an incorrect file view.

How to fix it

Apply the upstream fix that updates i_size and remote_i_size using start fpos plus the count returned by p9_client_write(); rebuild and deploy the corrected kernel to all affected hosts.

How to confirm the fix worked

Confirm the patched v9fs_issue_write() logic is present in the running kernel source or binary; exercise write workloads that extend files and verify both local i_size and remote file size are updated correctly.

Typical attack path

1. Mount a 9P filesystem from a vulnerable kernel
2. Issue writes that extend existing files past their recorded size
3. Trigger size-dependent operations (mmap, truncate, stat) that rely on the stale i_size
4. Observe or induce data corruption or access anomalies

How to detect it

Review kernel logs and 9P client traces for short-write handling around v9fs_issue_write; compare on-disk file lengths against client inode sizes after large writes.

What your security team should do

• Prioritize kernel updates on any system exposing 9P mounts
• Monitor upstream stable branches for the merged commit
• Test 9P workloads after patching to ensure size updates behave as expected