CVE-2026-99274 in Linux
Summary
by MITRE • 11/07/2026
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix fiemap wild read on empty truncated response
smb3_fiemap() treats -E2BIG from SMB2_ioctl() as a truncated range blob and loops for the next chunk. If the server reports STATUS_BUFFER_OVERFLOW with OutputCount == 0, SMB2_ioctl() returns -E2BIG with out_data == NULL and out_data_len == 0, and the existing length checks accept the empty result. The loop then evaluates
next = out_data[num - 1].file_offset + ...
with num == 0, reading 16 bytes before NULL.
Reject a truncated range blob that contains no range, so the resume offset is never computed from an empty response. Also require the last range in a truncated blob to advance the resume offset without overflowing, and to stay within the requested range; a malicious or broken server could otherwise make no progress or underflow len and loop forever. Free the previous response buffer before retrying.
Reproduced on 6.6.87.2 with a malicious SMB2 server that answers FSCTL_QUERY_ALLOCATED_RANGES with STATUS_BUFFER_OVERFLOW and OutputCount == 0; an FS_IOC_FIEMAP ioctl on the mount oopses in cifs_fiemap() with CR2 = fffffffffffffff8. The code path is unchanged on mainline.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 11/07/2026
The Linux kernel SMB client implementation contains a critical memory safety vulnerability within the fiemap functionality, specifically affecting the handling of truncated range blobs during FSCTL_QUERY_ALLOCATED_RANGES operations. This flaw arises from an incorrect interpretation of server responses that indicate buffer overflow conditions but contain no actual data payload. When the underlying SMB2_ioctl function receives a STATUS_BUFFER_OVERFLOW status code accompanied by an OutputCount of zero, it returns -E2BIG while leaving the output data pointer as NULL and its length as zero. The existing validation logic in cifs_fiemap fails to reject this empty result set, allowing execution to proceed under the false assumption that valid range information was retrieved despite the server indicating insufficient buffer space for a complete response.
The core technical flaw lies in the loop logic designed to process multiple chunks of allocated ranges from truncated responses. The code attempts to calculate the next offset by accessing an element at index num minus one, where num represents the number of entries processed so far. In this specific scenario involving an empty response, num equals zero, leading to a negative array index calculation that results in reading memory sixteen bytes before the NULL pointer. This out-of-bounds read triggers a kernel oops with CR2 set to fffffffffffffff8, indicating an invalid address access attempt. The vulnerability is exploitable by any SMB server configured or manipulated to return this specific malformed response pattern, effectively allowing remote code execution potential through privilege escalation if the attacker can control the memory layout surrounding the NULL pointer or cause denial of service via kernel panic.
From a security standards perspective, this issue maps directly to CWE-125 Out-of-bounds Read and CWE-400 Uncontrolled Resource Consumption due to the infinite loop risk described in the fix notes. The potential for an attacker to force no progress or underflow length variables creates conditions suitable for CWE-835 Loop with Unreachable Exit Condition, which can lead to denial of service by consuming CPU resources indefinitely if not properly bounded. Additionally, the ATT&CK framework classifies this type of exploitation vector as part of T1068 Exploitation for Privilege Escalation, since a kernel oops or crash in an SMB client context often serves as a precursor to further attacks against the host system's integrity and availability.
The operational impact extends beyond immediate crashes to include potential data corruption if the out-of-bounds read accesses sensitive memory structures before faulting. Systems relying on accurate file extent mapping for backup, deduplication, or storage optimization features may receive incorrect information or fail entirely when interacting with non-compliant or malicious SMB servers. This affects both local and networked filesystem mounts where fiemap operations are invoked to query allocated ranges of files. The vulnerability persists across kernel versions including 6.6.87.2 and mainline branches, indicating a systemic issue in the protocol handling logic rather than an isolated regression.
Mitigation requires immediate patching of the Linux kernel SMB client module to enforce stricter validation on truncated responses. Developers must ensure that any response marked as buffer overflow with zero output data is rejected outright before attempting to parse range entries. Furthermore, the loop condition should verify that each processed chunk advances the resume offset and remains within the originally requested file range boundaries to prevent infinite loops or underflow conditions. Administrators unable to patch immediately may consider restricting access to untrusted SMB servers or disabling fiemap-dependent features if available through configuration options. Regular auditing of kernel logs for similar oops patterns can help detect exploitation attempts in real time, although prevention via code correction remains the only reliable defense against this class of memory safety violations.