CVE-2026-98124: smb/client: invalidate fscache for fallocate range operations
In the Linux kernel, the following vulnerability has been resolved:
smb/client: invalidate fscache for fallocate range operations
smb3zerorange(), smb3punchhole(), smb3insertrange(), and smb3collapserange() modify file contents through server-side range operations. These operations discard the affected page cache, but leave the FS-Cache cookie valid, so a later read may return data cached before the range operation.
Fix this by invalidating FS-Cache after outstanding I/O has completed and before modifying the file on the server.
Run the following as root on a CIFS mount with fsc enabled and an active CacheFiles backend:
bash -c ' MNT=/mnt/cifs FILE="$MNT/repro"
# Generate four 1 MiB random blocks: [A][B][C][D]. dd if=/dev/urandom of=/tmp/src bs=1M count=4 status=none
# Expected contents after zeroing B: [A][zero][C][D]. cp /tmp/src /tmp/expected dd if=/dev/zero of=/tmp/expected bs=1M seek=1 count=1 \ conv=notrunc status=none cp /tmp/src "$FILE"
# Populate FS-Cache, then discard the page cache. sync echo 1 > /proc/sys/vm/dropcaches cat "$FILE" > /dev/null sync echo 1 > /proc/sys/vm/dropcaches
fallocate --zero-range -o 1M -l 1M "$FILE"
if cmp -s /tmp/expected "$FILE"; then echo "readback: OK" else echo "readback: STALE DATA" fi '
Before this change, the readback differs from /tmp/expected:
readback: STALE DATA
After this change, it matches:
readback: OK
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Operational
Invalidate FS-Cache after outstanding I/O has completed and before modifying the file on the server.
Event History
Frequently Asked Questions
Which systems are exposed to stale data reads?
Systems using a CIFS mount with FS-Cache enabled and an active CacheFiles backend are exposed when SMB client server-side range operations are used. The affected operations are zero range, punch hole, insert range, and collapse range.
What must occur for the issue to be observable?
A file's contents must be modified through one of the affected server-side range operations after data for that file has been cached in FS-Cache. A later read can then return data cached before the range operation instead of the updated server-side contents.
How can I check whether a system is affected?
The provided reproduction uses a CIFS mount with fsc enabled and an active CacheFiles backend, populates FS-Cache for a file, drops the page cache, performs fallocate --zero-range on a range, and compares the file with the expected contents. A mismatch indicates that a stale cached read occurred.