CVE-2026-98126: smb/client: validate new EOF for zero range
In the Linux kernel, the following vulnerability has been resolved:
smb/client: validate new EOF for zero range
When FALLOCFLZERORANGE is used without FALLOCFLKEEPSIZE, smb3zerorange() may extend EOF without checking RLIMITFSIZE, allowing the file to grow beyond the caller's file-size limit.
Fix this by calling inodenewsizeok() before sending the zero-range request when the operation would extend EOF.
Reproducer, using a file on a CIFS mount:
bash -c ' FILE=/mnt/cifs/repro
trap "" SIGXFSZ ulimit -f 3072
truncate -s 2M "$FILE" fallocate --zero-range -o 0 -l 4M "$FILE" echo "fallocate rc=$?" stat -c "file size=%s" "$FILE" '
Before this change, the operation succeeds despite the 3 MiB limit:
fallocate rc=0 file size=4194304
After this change, fallocate fails and leaves the file at 2 MiB.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
In smb3_zero_range(), call inode_newsize_ok() before sending the zero-range request when FALLOC_FL_ZERO_RANGE is used without FALLOC_FL_KEEP_SIZE, so the new EOF is validated against RLIMIT_FSIZE.
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
Systems using the Linux kernel SMB/CIFS client with files on a CIFS mount are affected when a process uses FALLOC_FL_ZERO_RANGE without FALLOC_FL_KEEP_SIZE and the operation extends the file beyond its current EOF.
What does an attacker or local user need to exploit it?
The user needs the ability to operate on a file on a CIFS mount and invoke a zero-range fallocate operation that extends the file. The impact occurs when the caller has an RLIMIT_FSIZE file-size limit that should prevent the extension.
How can I determine whether a system is affected?
On a CIFS mount, set a file-size limit of 3 MiB, create a 2 MiB file, then zero a 4 MiB range without keeping the file size. A vulnerable kernel allows the operation to succeed and grows the file to 4 MiB; a fixed kernel rejects it and leaves the file at 2 MiB.
What is the expected behavior after the fix?
When a zero-range request would extend EOF, the SMB client checks the proposed new size with inode_newsize_ok() before sending the request. Operations that exceed RLIMIT_FSIZE fail instead of extending the file.