CVE-2026-99274 · Runtime
NO FIX YET
A malicious or broken SMB server can send an empty truncated response that makes the Linux kernel's CIFS client read memory before a NULL pointer during an FS_IOC_FIEMAP call. The reproduced result is a kernel oops, which crashes the machine.
first public Nov 7, 2026 · 1 source
Check it with your coding agent
It checks your repository and tells you if you’re affected, with the fix.
Systems that mount SMB/CIFS shares with the Linux kernel client and reach a server that a hostile party could control or man-in-the-middle. The sources reproduce the crash only through an FS_IOC_FIEMAP ioctl on a mounted share, so hosts that never mount SMB shares are not exposed. The sources do not say which kernel versions are affected beyond the reproduction on 6.6.87.2 and that the code path is unchanged on mainline.
Not affected if no-cifs-mounts, trusted-smb-server
Who cares cifs, file-servers, linux-kernel, smb
mount -t cifs or lsblk-visible CIFS filesystems, using findmnt -t cifsuname -rUnknown from the sources.
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.
Are you affected?
Tell InfraStack what you run. It checks this one, and every next one, against your stack.
Ask from here. InfraStack checks the affected versions against your stack and answers in your inbox.
InfraStack checks the affected versions against your stack and answers in Slack, with the evidence and the fix.
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.