---
id: "CVE-2026-99115"
kind: "vulnerability"
aliases: ["CVE-2026-99115"]
title: "Linux kernel ksmbd: SMB compound request can leak stale kernel memory"
severity: "unknown"
cvss: null
epss: null
exploited: false
status: "open"
category: "runtime"
products: []
ecosystems: []
tags: ["file-servers", "ksmbd", "linux-kernel", "runtime", "self-hosted"]
not_affected_if: ["ksmbd-not-loaded", "samba-only"]
published_at: "2026-10-28T11:17:31+00:00"
first_seen_at: "2026-10-28T11:32:34+00:00"
updated_at: "2026-10-28T11:37:39+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-99115", "first_seen_at": "2026-10-28T11:32:34+00:00"}]
---

# Linux kernel ksmbd: SMB compound request can leak stale kernel memory

ksmbd, the in-kernel SMB server, returns eight bytes of the FileSysIdentifier field in FS_POSIX_INFORMATION that were never set. In a compound SMB request, those bytes can hold leftover data from a previously dropped response, so a client may read kernel memory.

_Summary, check and fix written by a model from the sources; labelled as such._

## How to check

- unknown

## Fix

- Update the Linux kernel to a release that includes the upstream commit filling in FileSysIdentifier in ksmbd (fixed version not stated in the source)
- Unload or disable the ksmbd module if SMB serving from the kernel is not needed (`lsmod | grep ksmbd`)

## Timeline

- 2026-10-28T11:32:34+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-99115

## From the sources

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.

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_