Cloudanix VulnDB

CVE-2026-99114

None

CVSS

—

EPSS

0.2%

Published

Oct 28, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in the Linux kernel's built-in file sharing code could let remote users see tiny pieces of internal memory that should have stayed hidden.

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

What it actually does

ksmbd's smb2_get_info_filesystem() returns a 48-byte FS_CONTROL_INFORMATION structure without initializing the FileSystemControlFlags field; in compound requests a prior dropped response buffer can remain partially intact, leaking up to four bytes of kernel memory to the client.

Why it matters to the business

Attackers may obtain small fragments of kernel memory that could contain sensitive data such as pointers or credentials, increasing the risk of further exploitation on exposed SMB servers.

How an attack unfolds

An attacker establishes an SMB2 session and issues a compound request containing an FS_CONTROL_INFORMATION query followed by a second command that triggers an error path; the server overlays only the header of the second reply, leaving residual data from the first reply (including uninitialized flags) in the response that is sent to the client.

How to fix it

Apply the upstream kernel patch that initializes FileSystemControlFlags to zero before returning FS_CONTROL_INFORMATION; rebuild and deploy the fixed kernel on all systems running ksmbd.

How to confirm the fix worked

Confirm the patch is present by inspecting the source of smb2_get_info_filesystem() to verify FileSystemControlFlags is explicitly set; test with compound requests to ensure the four flag bytes are always zero in responses.

Typical attack path

  1. Establish authenticated SMB2 connection to ksmbd
  2. Craft compound SMB2 request with FS_CONTROL_INFORMATION query as first element
  3. Include a second command engineered to produce an error response
  4. Receive the compound reply containing leaked bytes from the prior buffer
  5. Repeat to harvest additional kernel memory fragments

How to detect it

Inspect SMB2 response logs and packet captures for FS_CONTROL_INFORMATION replies whose FileSystemControlFlags field contains non-zero values or unexpected data patterns inconsistent with a fresh zeroed buffer.

What your security team should do

  • Prioritize patching all internet-facing or internal ksmbd deployments within the next 7 days
  • Disable ksmbd if SMB file sharing is not required on the host
  • Monitor for unusual compound SMB2 request patterns until patches are applied

The record

In the Linux kernel, the following vulnerability has been resolved: ksmbd: initialize FileSystemControlFlags in FS_CONTROL_INFORMATION smb2_get_info_filesystem() reports 48 bytes for FS_CONTROL_INFORMATION, that is the whole of struct smb2_fs_control_info, but never assigns FileSystemControlFlags. Those four bytes go to the client as they are found in the response buffer. The buffer is zeroed on allocation, so a standalone request leaks nothing. A compound request can leak: the offset of the next response is advanced by the length pinned for the previous one, so a reply that was written into the buffer and then dropped in favour of the short error response of smb2_set_err_rsp() stays there, and the next reply is laid over it with only the header cleared. ksmbd does not implement quota tracking, so report no control flags.

Affected packages

Ecosystem Package Introduced Fixed