CVE-2026-99109 in Linux
Summary
by MITRE • 10/28/2026
In the Linux kernel, the following vulnerability has been resolved:
smb: client: reject SetEA requests that do not fit the request buffer
CIFSSMBSetEA() copies the caller's extended attribute value into the SMB request buffer without checking that it fits. The requirement is stated in the source but was never implemented:
/*BB add length check to see if it would fit in negotiated SMB buffer size BB */ /* if (ea_value_len > buffer_size - 512 (enough for header)) */ if (ea_value_len) memcpy(parm_data->list.name + name_len + 1, ea_value, ea_value_len);
The only bound applied on the way in is in cifs_xattr_set():
#define MAX_EA_VALUE_SIZE CIFSMaxBufSize ... if (size > MAX_EA_VALUE_SIZE)
CIFSMaxBufSize is the full payload capacity of the buffer, so a value of exactly that size leaves no room for the SMB header, the TRANS2 parameter block, the fealist header and the EA name that are written ahead of it in the same object.
SendReceive() already enforces the correct limit on this very length:
if (in_len > CIFSMaxBufSize + MAX_CIFS_HDR_SIZE)
but it is called after the copy has taken place. An unprivileged setxattr(2) on an SMB1 mount with a 250-byte name and a 16384-byte value writes 16384 bytes starting 345 bytes into a 16588-byte cifs_request object, ending 141 bytes past it:
BUG: KASAN: slab-out-of-bounds in CIFSSMBSetEA+0xabc/0xde0 Write of size 16384 at addr ffff888003aa0159 by task init/68 __asan_memcpy+0x3c/0x60 CIFSSMBSetEA+0xabc/0xde0 cifs_xattr_set+0xd3a/0xff0 __vfs_setxattr+0x13e/0x1a0 The buggy address is located 345 bytes inside of allocated 16588-byte region
Apply SendReceive()'s limit to the assembled request before the copy rather than after it, and widen the byte counters so the sum cannot wrap before it is tested.
byte_count is also tested against U16_MAX, because it is stored in the 16-bit pSMB->ByteCount. That becomes reachable when CIFSMaxBufSize is raised at module load, where it may be set as high as 1024*127: with a 5-byte EA name and a 65521-byte value, count is exactly U16_MAX while byte_count is 65556, and cpu_to_le16() would truncate it to 20 and transmit a frame whose ByteCount does not match its length. Testing byte_count covers count as well, since byte_count is the larger of the two and count's only 16-bit consumer is written after this point.
check_add_overflow() is evaluated first so that total_len is assigned before it is reported.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/28/2026
The Linux kernel SMB client implementation contained a critical buffer overflow vulnerability within the CIFSSMBSetEA function, which handles Extended Attribute (EA) set requests for CIFS and SMB1 mounts. This flaw stemmed from an incomplete security check where the code failed to verify that the extended attribute value being copied into the request buffer would fit within the allocated memory space. Although source comments indicated a requirement to validate this length against the negotiated SMB buffer size, the corresponding logic was never implemented in the actual execution path. Consequently, when a user invoked the setxattr system call with an EA name and value that exceeded the available payload capacity of the request structure, the kernel performed an unchecked memory copy operation. This resulted in writing data beyond the bounds of the allocated slab object, triggering a Kernel Address Sanitizer (KASAN) error indicative of a slab-out-of-bounds write condition.
From a technical perspective, the vulnerability arises because the initial validation layer only enforced a maximum size based on CIFSMaxBufSize without accounting for the overhead required by protocol headers and metadata structures. The total request object includes not just the EA value but also the SMB header, TRANS2 parameter block, FEAST header, and the EA name itself. By allowing an EA value that consumes nearly the entire buffer capacity, the subsequent addition of these fixed-size components causes the write pointer to exceed the allocated region. For instance, a scenario involving a 250-byte name and a large value could result in writing thousands of bytes past the end of a roughly sixteen-thousand-byte allocation structure. This memory corruption poses significant risks as it can lead to kernel crashes, data integrity issues, or potentially be exploited for arbitrary code execution if an attacker can control the overwritten memory contents and their subsequent interpretation by the kernel.
The operational impact of this vulnerability is severe due to its potential for remote exploitation in networked environments using SMB1 protocols. An unprivileged local user on a system with mounted CIFS shares could trigger this condition, leading to denial-of-service through kernel panics or potentially escalating privileges if the memory corruption affects critical control structures. This aligns with CWE-787: Out-of-bounds Write and reflects common patterns found in ATT&CK technique T1059: Command and Scripting Interpreter where local exploits are used to disrupt system availability or gain unauthorized access. The flaw highlights a classic race condition between logical validation and memory allocation, where the check for total packet size occurred after the dangerous copy operation had already taken place during request assembly.
To mitigate this vulnerability, developers implemented strict bounds checking prior to any memory copying operations within the CIFSSMBSetEA function. The fix ensures that the sum of all components required for a valid SMB transaction is calculated and validated against CIFSMaxBufSize before initiating the memcpy call. Additionally, the patch addresses potential integer overflow issues by widening byte counters to prevent wraparound errors during arithmetic calculations involving buffer sizes. It also introduces checks against U16_MAX limits for fields like ByteCount that are stored in 16-bit structures within the protocol header, ensuring that truncated values do not result in malformed network frames with mismatched length indicators. These changes enforce a defense-in-depth approach by validating input constraints at the earliest possible stage of request processing, thereby preventing out-of-bounds writes and maintaining the integrity of kernel memory allocations during SMB client operations.