Cloudanix VulnDB

CVE-2026-99109

None

CVSS

—

EPSS

0.2%

Published

Oct 28, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in Linux's handling of file properties over older network file shares can let local users crash the system or potentially gain higher privileges.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Privilege Gain
Component
OS kernel
Class
Buffer Overflow
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

Out-of-bounds write via memcpy in CIFSSMBSetEA when an EA value larger than remaining buffer space after headers is supplied on an SMB1 mount; the check in SendReceive occurs after the copy and CIFSMaxBufSize permits values that overflow the cifs_request object.

Why it matters to the business

Kernel memory corruption on systems mounting SMB1 shares can cause crashes, denial of service, or local privilege escalation; recent publication and lack of widespread mitigations increase immediate exposure for organizations still using legacy SMB1.

How an attack unfolds

An unprivileged local user issues setxattr on a file in an SMB1-mounted share; cifs_xattr_set passes a large value that fits the MAX_EA_VALUE_SIZE check but exceeds space left after SMB headers and EA name, resulting in memcpy writing past the end of the allocated cifs_request buffer.

How to fix it

Apply the upstream kernel patch that moves the SendReceive length check before the memcpy, uses check_add_overflow on the assembled request size, and additionally validates against U16_MAX; rebuild and reboot with the fixed kernel; disable SMB1 mounts where possible until patched.

How to confirm the fix worked

Inspect the patched CIFSSMBSetEA for the byte_count overflow test and check_add_overflow guard before any memcpy; confirm absence of the KASAN slab-out-of-bounds report when repeating the oversized setxattr test on a patched kernel.

Typical attack path

  1. Mount an SMB1 share with the cifs module
  2. Invoke setxattr(2) with a name exceeding 250 bytes and value near 16384 bytes
  3. Trigger CIFSSMBSetEA which performs unchecked memcpy into the request buffer
  4. Cause slab-out-of-bounds write leading to KASAN panic or controlled memory corruption

How to detect it

Search kernel logs for KASAN slab-out-of-bounds messages referencing CIFSSMBSetEA or cifs_xattr_set; inspect audit logs for setxattr syscalls targeting paths on cifs mounts with unusually large values.

  • CIFSSMBSetEA+0xabc
  • BUG: KASAN: slab-out-of-bounds in CIFSSMBSetEA
  • cifs_xattr_set
  • Write of size 16384 at addr

What your security team should do

  • Disable SMB1 protocol support at the client and server level immediately
  • Prioritize kernel updates containing the CIFSSMBSetEA length-check fix
  • Audit systems for any remaining SMB1 mounts and replace with SMB2/SMB3
  • Add monitoring for cifs module activity and setxattr calls on network filesystems

The record

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.

Affected packages

Ecosystem Package Introduced Fixed