---
id: "CVE-2026-99113"
kind: "vulnerability"
aliases: ["CVE-2026-99113"]
title: "Linux ksmbd: stale kernel memory leaks in compound SMB filesystem info replies"
severity: "low"
cvss: null
epss: null
exploited: false
status: "open"
category: "runtime"
products: []
ecosystems: []
tags: ["file-server", "kernel", "ksmbd", "linux", "runtime", "self-hosted"]
not_affected_if: ["ksmbd-not-loaded", "no-smb-shares", "samba-instead"]
published_at: "2026-10-28T11:17:30+00:00"
first_seen_at: "2026-10-28T11:32:34+00:00"
updated_at: "2026-10-28T11:37:42+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-99113", "first_seen_at": "2026-10-28T11:32:34+00:00"}]
---

# Linux ksmbd: stale kernel memory leaks in compound SMB filesystem info replies

ksmbd, the in-kernel SMB server, fills the FS_OBJECT_ID_INFORMATION reply without zeroing its 64-byte buffer, so in a compound request leftover bytes from an earlier reply can be sent to the client. An authenticated SMB client can read up to 31 bytes of kernel memory per affected reply, including data from a reply that failed with access denied.

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

## How to check

- Check whether ksmbd is loaded on the host with `lsmod | grep ksmbd` or `modinfo ksmbd`
- Check the running kernel with `uname -r` and compare it to the fixed stable release listed by the kernel advisory
- unknown whether a specific kernel version range is affected; the sources do not list one

## Fix

- Update the Linux kernel to a stable release that includes the upstream commit zeroing the FS_OBJECT_ID_INFORMATION buffer, `unknown` version
- If ksmbd is not needed, unload it with `rmmod ksmbd` or disable the ksmbd service
- unknown whether a distribution backport or mitigation exists; the sources do not say

## Timeline

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

## From the sources

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.

---

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