CVE-2026-98127 in Linux
Summary
by MITRE • 09/25/2026
In the Linux kernel, the following vulnerability has been resolved:
smb/client: validate new EOF for insert range
smb3_insert_range() does not check if the new file size (i_size + len) is valid. This allows FALLOC_FL_INSERT_RANGE to bypass RLIMIT_FSIZE, exceed s_maxbytes, or produce a size outside the loff_t range.
Use check_add_overflow() to calculate the new EOF. Validate it with inode_newsize_ok() before modifying the file.
Reproducer, using a file on a CIFS mount:
bash -c ' FILE=/mnt/cifs/repro
trap "" SIGXFSZ ulimit -f 3072 # RLIMIT_FSIZE = 3 MiB
# A regular write is stopped at 3 MiB. dd if=/dev/zero of="$FILE" bs=1M count=4 status=none stat -c "size after write: %s" "$FILE"
# Insert 2 MiB into a 2 MiB file. truncate -s 2M "$FILE" fallocate -i -o 0 -l 2M "$FILE" stat -c "size after insert: %s" "$FILE" '
Before this change, the regular write stops at the 3 MiB limit, but insert range grows the file to 4 MiB:
dd: error writing '/mnt/cifs/repro': File too large size after write: 3145728 size after insert: 4194304
After this change, insert range also fails at the limit and leaves the 2 MiB file unchanged:
dd: error writing '/mnt/cifs/repro': File too large size after write: 3145728 fallocate: fallocate failed: File too large size after insert: 2097152
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/25/2026
The Linux kernel SMB client implementation contained a critical validation flaw within the smb3_insert_range function, which is responsible for handling the FALLOC_FL_INSERT_RANGE operation. This system call allows applications to allocate space in the middle of an existing file by shifting data from a specified offset forward by a given length. The vulnerability stems from the absence of checks on the resulting end-of-file position after such an insertion. Specifically, the code failed to verify whether the new file size, calculated as the sum of the current inode size and the requested insert length, adhered to system constraints or architectural limits. This oversight created a significant security gap where standard resource control mechanisms were effectively bypassed during this specific type of file manipulation operation.
The operational impact of this vulnerability is severe because it allows processes to circumvent RLIMIT_FSIZE restrictions. Under normal circumstances, the kernel enforces soft and hard limits on file sizes through signals like SIGXFSZ or by returning an EFBIG error when a write exceeds these bounds. However, because smb3_insert_range did not validate the new end-of-file position against inode_newsize_ok before modifying the file structure, attackers could exploit this to grow files beyond permitted limits. This behavior also poses risks related to exceeding s_maxbytes, which represents the maximum supported file size for the filesystem type, and potentially causing integer overflows if the calculated offset exceeds the range of a loff_t variable. Such conditions can lead to memory corruption or undefined kernel behavior depending on how subsequent operations handle these invalid sizes.
From a technical perspective, this issue is classified under CWE-20 Improper Input Validation and CWE-787 Out-of-bounds Write in contexts where internal structures might be corrupted due to the oversized file metadata updates. In terms of attack vectors, it aligns with ATT&CK techniques related to resource exhaustion or privilege escalation via local exploitation if combined with other vulnerabilities that depend on specific file states. The lack of overflow checking during arithmetic operations involving file sizes is a common source of such flaws in kernel codebases, highlighting the necessity for robust integer safety checks before any state modification occurs.
The resolution involves integrating check_add_overflow to safely compute the new end-of-file position and ensuring that inode_newsize_ok validates this result against all relevant constraints including RLIMIT_FSIZE, s_maxbytes, and loff_t boundaries. By performing these validations prior to altering the file size, the kernel ensures consistent enforcement of resource limits regardless of whether data is appended via standard writes or inserted via fallocate operations. This fix restores parity between different methods of file modification and prevents unauthorized expansion of files on CIFS mounts. System administrators should apply updates that include this patch immediately to mitigate risks associated with local privilege escalation attempts or denial-of-service scenarios stemming from uncontrolled resource consumption through crafted SMB client requests.