Cloudanix VulnDB

CVE-2026-99115

None

CVSS

—

EPSS

0.2%

Published

Oct 28, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in Linux file-sharing code could let connected clients see tiny pieces of the server's internal memory.

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

What it actually does

Uninitialized or prior buffer contents (up to 8 bytes of FileSysIdentifier in FS_POSIX_INFORMATION) can be leaked to SMB clients when smb2_get_info_filesystem() returns a short error response in a compound request; the buffer is zero-initialized on allocation but prior reply data survives when only the header is cleared.

Why it matters to the business

Limited kernel memory disclosure that may reveal filesystem identifiers or adjacent data, potentially aiding reconnaissance; published one day ago with no known exploitation or ransomware use, so immediate operational risk is low but patch urgency rises once public exploits appear.

How an attack unfolds

An attacker establishes an SMB session to a ksmbd server, issues compound requests that query filesystem information and deliberately trigger error paths, then inspects subsequent replies for residual data left from earlier responses in the same compound chain.

How to fix it

Upgrade the Linux kernel to a version that includes the ksmbd fix assigning FileSysIdentifier from statfs() before returning FS_POSIX_INFORMATION; rebuild and reboot affected systems once the patch is available in distribution kernels.

How to confirm the fix worked

Confirm the kernel source contains the assignment of val[0]/val[1] from f_fsid and the le64 conversion into FileSysIdentifier; test by sending compound requests and verifying the field now contains the expected filesystem identifier rather than prior buffer contents.

Typical attack path

  1. Establish authenticated or guest SMB session to ksmbd
  2. Craft compound SMB2 GET_INFO requests for FS_POSIX_INFORMATION
  3. Force error responses via smb2_set_err_rsp
  4. Parse leaked bytes from the FileSysIdentifier field in later replies

How to detect it

Review SMB server logs and network captures for compound requests that elicit error responses followed by FS_POSIX_INFORMATION replies; inspect response buffers for non-zero or unexpected values in the eight-byte FileSysIdentifier field.

What your security team should do

  • Apply the upstream ksmbd fix as soon as distribution kernels are released
  • Disable ksmbd on systems where SMB serving is not required
  • Monitor EPSS and exploit maturity indicators for rapid response once public code appears

The record

In the Linux kernel, the following vulnerability has been resolved: ksmbd: fill in FileSysIdentifier in FS_POSIX_INFORMATION smb2_get_info_filesystem() reports 56 bytes for FS_POSIX_INFORMATION, that is the whole of FILE_SYSTEM_POSIX_INFO, but never assigns FileSysIdentifier. Those eight 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. Report the file system id statfs() returned, which is what the field is for. FileSysIdentifier is __le64 and f_fsid is a pair of ints, so assemble the value first, val[0] as the low half, and convert it on the way out.

Affected packages

Ecosystem Package Introduced Fixed