Cloudanix VulnDB

CVE-2026-99113

None

CVSS

—

EPSS

0.2%

Published

Oct 28, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A recent Linux kernel bug in file sharing could let remote users receive small pieces of other server responses they were never meant to see.

Exploitation
Remote Authenticated
Attacker needs
Low Privilege
Complexity
Moderate
Impact
Data Exposure
Component
OS kernel
Class
Information Disclosure
Remediation
Patch
Effort
Low
Patch risk
Low

What it actually does

Uninitialized buffer bytes in FS_OBJECT_ID_INFORMATION responses from ksmbd allow up to 31 bytes of prior reply data (including from failed access-denied commands) to be returned to clients in compound SMB2 requests.

Why it matters to the business

Organizations running Linux-based file servers risk unintended disclosure of internal response data over SMB, which could aid reconnaissance or expose sensitive operational details.

How an attack unfolds

An attacker crafts a compound SMB2 request containing a command expected to fail followed by an FS_OBJECT_ID_INFORMATION query; when the failing command's short error response is pinned, the subsequent reply reuses uncleared buffer space and leaks prior content to the client.

How to fix it

Apply the upstream kernel patch that zeros the object_id_info structure before populating it in smb2_get_info_filesystem(); rebuild and deploy updated kernel packages containing the fix.

How to confirm the fix worked

Confirm the patch is present by inspecting the ksmbd source for the added zeroing step before the structure is filled, then test compound requests to verify no prior-response leakage occurs.

Typical attack path

  1. Establish SMB2 session to ksmbd target
  2. Issue compound request with a deliberately failing command then FS_OBJECT_ID_INFORMATION
  3. Inspect response for extraneous data beyond the declared 46 bytes

How to detect it

Review SMB2 logs and network captures for compound requests that combine error-inducing commands with filesystem info queries; inspect response lengths and content for anomalies exceeding expected 46-byte payloads.

What your security team should do

  • Prioritize kernel updates for any systems exposing ksmbd
  • Review SMB exposure and restrict unnecessary compound request support if patching is delayed
  • Monitor vendor advisories for backported fixes

The record

In the Linux kernel, the following vulnerability has been resolved: ksmbd: zero the FS_OBJECT_ID_INFORMATION buffer before filling it in smb2_get_info_filesystem() reports 64 bytes for FS_OBJECT_ID_INFORMATION, that is the whole of struct object_id_info, but writes only 46 of them: - objid[] is 16 bytes, and when the volume UUID is not available only sizeof(stfs.f_fsid) (8) bytes are copied into it; - extended_info.version_string[] is STRING_LENGTH (28) bytes, and only strlen("1.1.0") (5) bytes are copied into it. The response buffer is zeroed on allocation (kvzalloc() in smb2_allocate_rsp_buf()), so for a standalone request the remaining 31 bytes are zero. In a compound request they need not be. The offset of the next response is advanced by the length pinned for the previous one, so if a preceding command wrote its reply into the buffer and then failed, smb2_set_err_rsp() pins only the short error response and the next reply lands inside the area that has already been written. Only the header is cleared there: memset((char *)rsp_hdr, 0, sizeof(struct smb2_hdr) + 2); The client then receives up to 31 bytes of a response it was not meant to see, including one that failed with an access denied error. Clear the structure before filling it in. As a side effect version_string is now NUL terminated.

Affected packages

Ecosystem Package Introduced Fixed