[PATCH] ksmbd: zero the object ID before filling FS_OBJECT_ID_INFORMATION

[PATCH] ksmbd: zero the object ID before filling FS_OBJECT_ID_INFORMATION

[Aleksandr Khromov]

FS_OBJECT_ID_INFORMATION reports 64 bytes to the client, so all 16 bytes
of object_id_info::objid are sent.  When the volume UUID is not available
only sizeof(stfs.f_fsid) (8 bytes) is copied, and the remaining 8 bytes
are whatever the response buffer holds.

The response buffer is zeroed on allocation (kzalloc()/kvzalloc()), so
for a standalone request the tail is zero.  In a compound request it 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 already written.  Only
the header is cleared there:

	memset((char *)rsp_hdr, 0, sizeof(struct smb2_hdr) + 2);

Clear the field before filling it in.

Fixes: 3a64125730ca ("ksmbd: use volume UUID in FS_OBJECT_ID_INFORMATION")
Cc: stable@vger.kernel.org
Signed-off-by: Aleksandr Khromov <haa@amicon.ru>
---
 fs/smb/server/smb2pdu.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/fs/smb/server/smb2pdu.c b/fs/smb/server/smb2pdu.c
index 76f63f9adc72..6f5f4a399bde 100644
--- a/fs/smb/server/smb2pdu.c
+++ b/fs/smb/server/smb2pdu.c
@@ -6093,6 +6093,7 @@ static int smb2_get_info_filesystem(struct ksmbd_work *work,
 
 		info = (struct object_id_info *)(rsp->Buffer);
 
+		memset(info->objid, 0, sizeof(info->objid));
 		if (path.mnt->mnt_sb->s_uuid_len == 16)
 			memcpy(info->objid, path.mnt->mnt_sb->s_uuid.b,
 					path.mnt->mnt_sb->s_uuid_len);
-- 
2.48.1

Re: [PATCH] ksmbd: zero the object ID before filling FS_OBJECT_ID_INFORMATION

[ChenXiaoSong]

Should we clear `info`? Will `info->extended_info.version_string` also leak?

```
7437         case FS_OBJECT_ID_INFORMATION:
7438         {
7439                 struct object_id_info *info;
7440
7441                 info = (struct object_id_info *)(rsp->Buffer);
...
7454                 memcpy(info->extended_info.version_string, "1.1.0", 
strlen("1.1.0"));
7455                 rsp->OutputBufferLength = cpu_to_le32(64);
...
7458         }
```

On 8/21/2026 9:58 PM, Aleksandr Khromov wrote:
> --- a/fs/smb/server/smb2pdu.c
> +++ b/fs/smb/server/smb2pdu.c
> @@ -6093,6 +6093,7 @@ static int smb2_get_info_filesystem(struct ksmbd_work *work,
>   
>   		info = (struct object_id_info *)(rsp->Buffer);
>   
> +		memset(info->objid, 0, sizeof(info->objid));
>   		if (path.mnt->mnt_sb->s_uuid_len == 16)
>   			memcpy(info->objid, path.mnt->mnt_sb->s_uuid.b,
>   					path.mnt->mnt_sb->s_uuid_len);

-- 
ChenXiaoSong <chenxiaosong@chenxiaosong.com>
Chinese Homepage: https://chenxiaosong.com
English Homepage: https://chenxiaosong.com/en

[PATCH v2 0/3] ksmbd: fix information leaks in smb2_get_info_filesystem()

[Aleksandr Khromov]

smb2_get_info_filesystem() sets rsp->OutputBufferLength to the full size
of the structure of the requested info level, but three levels leave
part of that structure unwritten:

  FS_OBJECT_ID_INFORMATION  31 of 64 bytes (objid[] tail when the volume
                            UUID is unavailable, plus version_string[])
  FS_CONTROL_INFORMATION     4 of 48 bytes (FileSystemControlFlags)
  FS_POSIX_INFORMATION       8 of 56 bytes (FileSysIdentifier)

The response buffer is zeroed on allocation, so a standalone request
returns zeros there.  A compound request need not:
work->next_smb2_rsp_hdr_off is advanced by the length pinned for the
previous response, so if a command wrote its reply into the buffer and
then failed, smb2_set_err_rsp() pins only the short error response and
the next reply is laid over the bytes already written.  Only the header
is cleared at that point:

	memset((char *)rsp_hdr, 0, sizeof(struct smb2_hdr) + 2);

What leaks is not arbitrary kernel memory but a reply that ksmbd built
for the same connection and did not send, including one that failed with
an access denied error.

Compile tested only (x86_64_defconfig + CONFIG_SMB_SERVER=m).

v2: v1 was a single patch clearing only objid[].  ChenXiaoSong asked in
    review whether extended_info.version_string leaks as well; it does,
    and so do the other two levels, so v2 clears the whole structure in
    patch 1 and adds patches 2 and 3.  All three go back to the original
    ksmbd import rather than to commit 3a64125730ca ("ksmbd: use volume
    UUID in FS_OBJECT_ID_INFORMATION"), so the Fixes: tags moved
    accordingly; on trees without that commit patch 1 needs a trivial
    context fixup.
    v1: https://lore.kernel.org/linux-cifs/20260821135801.3790290-1-haa@amicon.ru/

Aleksandr Khromov (3):
  ksmbd: zero the FS_OBJECT_ID_INFORMATION buffer before filling it in
  ksmbd: initialize FileSystemControlFlags in FS_CONTROL_INFORMATION
  ksmbd: fill in FileSysIdentifier in FS_POSIX_INFORMATION

 fs/smb/server/smb2pdu.c | 4 ++++
 1 file changed, 4 insertions(+)

-- 
2.48.1

[PATCH v2 1/3] ksmbd: zero the FS_OBJECT_ID_INFORMATION buffer before filling it in

[Aleksandr Khromov]

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.

Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3")
Suggested-by: ChenXiaoSong <chenxiaosong@chenxiaosong.com>
Cc: stable@vger.kernel.org
Signed-off-by: Aleksandr Khromov <haa@amicon.ru>
---
 fs/smb/server/smb2pdu.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/fs/smb/server/smb2pdu.c b/fs/smb/server/smb2pdu.c
index 76f63f9adc72..a66a7a12477b 100644
--- a/fs/smb/server/smb2pdu.c
+++ b/fs/smb/server/smb2pdu.c
@@ -6092,6 +6092,7 @@ static int smb2_get_info_filesystem(struct ksmbd_work *work,
 		struct object_id_info *info;
 
 		info = (struct object_id_info *)(rsp->Buffer);
+		memset(info, 0, sizeof(*info));
 
 		if (path.mnt->mnt_sb->s_uuid_len == 16)
 			memcpy(info->objid, path.mnt->mnt_sb->s_uuid.b,
-- 
2.48.1

[PATCH v2 2/3] ksmbd: initialize FileSystemControlFlags in FS_CONTROL_INFORMATION

[Aleksandr Khromov]

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.

Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3")
Cc: stable@vger.kernel.org
Signed-off-by: Aleksandr Khromov <haa@amicon.ru>
---
 fs/smb/server/smb2pdu.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/fs/smb/server/smb2pdu.c b/fs/smb/server/smb2pdu.c
index a66a7a12477b..5e83ad4f085e 100644
--- a/fs/smb/server/smb2pdu.c
+++ b/fs/smb/server/smb2pdu.c
@@ -6145,6 +6145,7 @@ static int smb2_get_info_filesystem(struct ksmbd_work *work,
 		info->FreeSpaceStopFiltering = 0;
 		info->DefaultQuotaThreshold = cpu_to_le64(SMB2_NO_FID);
 		info->DefaultQuotaLimit = cpu_to_le64(SMB2_NO_FID);
+		info->FileSystemControlFlags = 0;
 		info->Padding = 0;
 		rsp->OutputBufferLength = cpu_to_le32(48);
 		break;
-- 
2.48.1

[PATCH v2 3/3] ksmbd: fill in FileSysIdentifier in FS_POSIX_INFORMATION

[Aleksandr Khromov]

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; ksmbd already hands the same value out in FS_OBJECT_ID_INFORMATION
when the volume UUID is not available.

Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3")
Cc: stable@vger.kernel.org
Signed-off-by: Aleksandr Khromov <haa@amicon.ru>
---
 fs/smb/server/smb2pdu.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/fs/smb/server/smb2pdu.c b/fs/smb/server/smb2pdu.c
index 5e83ad4f085e..7f200ba103ba 100644
--- a/fs/smb/server/smb2pdu.c
+++ b/fs/smb/server/smb2pdu.c
@@ -6167,6 +6167,8 @@ static int smb2_get_info_filesystem(struct ksmbd_work *work,
 			info->UserBlocksAvail = cpu_to_le64(stfs.f_bavail);
 			info->TotalFileNodes = cpu_to_le64(stfs.f_files);
 			info->FreeFileNodes = cpu_to_le64(stfs.f_ffree);
+			memcpy(&info->FileSysIdentifier, &stfs.f_fsid,
+			       sizeof(stfs.f_fsid));
 			rsp->OutputBufferLength = cpu_to_le32(56);
 		}
 		break;
-- 
2.48.1

Re: [PATCH v2 3/3] ksmbd: fill in FileSysIdentifier in FS_POSIX_INFORMATION

[Namjae Jeon]

On Mon, Aug 24, 2026 at 7:23 PM Aleksandr Khromov <haa@amicon.ru> wrote:
>
> 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; ksmbd already hands the same value out in FS_OBJECT_ID_INFORMATION
> when the volume UUID is not available.
>
> Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3")
> Cc: stable@vger.kernel.org
> Signed-off-by: Aleksandr Khromov <haa@amicon.ru>
> ---
>  fs/smb/server/smb2pdu.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/fs/smb/server/smb2pdu.c b/fs/smb/server/smb2pdu.c
> index 5e83ad4f085e..7f200ba103ba 100644
> --- a/fs/smb/server/smb2pdu.c
> +++ b/fs/smb/server/smb2pdu.c
> @@ -6167,6 +6167,8 @@ static int smb2_get_info_filesystem(struct ksmbd_work *work,
>                         info->UserBlocksAvail = cpu_to_le64(stfs.f_bavail);
>                         info->TotalFileNodes = cpu_to_le64(stfs.f_files);
>                         info->FreeFileNodes = cpu_to_le64(stfs.f_ffree);
> +                       memcpy(&info->FileSysIdentifier, &stfs.f_fsid,
> +                              sizeof(stfs.f_fsid));
Since FileSysIdentifier is __le64, endianness conversion is needed.
Thanks.

Re: [PATCH v2 1/3] ksmbd: zero the FS_OBJECT_ID_INFORMATION buffer before filling it in

[Namjae Jeon]

On Mon, Aug 24, 2026 at 7:23 PM Aleksandr Khromov <haa@amicon.ru> wrote:
>
> 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.
>
> Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3")
> Suggested-by: ChenXiaoSong <chenxiaosong@chenxiaosong.com>
> Cc: stable@vger.kernel.org
> Signed-off-by: Aleksandr Khromov <haa@amicon.ru>
Applied it to #ksmbd-for-next.
Thanks!

Re: [PATCH v2 2/3] ksmbd: initialize FileSystemControlFlags in FS_CONTROL_INFORMATION

[Namjae Jeon]

On Mon, Aug 24, 2026 at 7:23 PM Aleksandr Khromov <haa@amicon.ru> wrote:
>
> 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.
>
> Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3")
> Cc: stable@vger.kernel.org
> Signed-off-by: Aleksandr Khromov <haa@amicon.ru>
Applied it to #ksmbd-for-next.
Thanks!

[PATCH v3] ksmbd: fill in FileSysIdentifier in FS_POSIX_INFORMATION

[Aleksandr Khromov]

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.

Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3")
Cc: stable@vger.kernel.org
Signed-off-by: Aleksandr Khromov <haa@amicon.ru>
---
v3: FileSysIdentifier is __le64, so assemble the value and convert it
    instead of memcpy()ing the host representation of f_fsid into the
    field (Namjae Jeon).  Patches 1/3 and 2/3 of v2 were applied to
    ksmbd-for-next, so this is the only one left of the series.
v2: https://lore.kernel.org/linux-cifs/20260824102248.178152-4-haa@amicon.ru/

 fs/smb/server/smb2pdu.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/fs/smb/server/smb2pdu.c b/fs/smb/server/smb2pdu.c
index 5e83ad4f085e..a5771474b2af 100644
--- a/fs/smb/server/smb2pdu.c
+++ b/fs/smb/server/smb2pdu.c
@@ -6167,6 +6167,9 @@ static int smb2_get_info_filesystem(struct ksmbd_work *work,
 			info->UserBlocksAvail = cpu_to_le64(stfs.f_bavail);
 			info->TotalFileNodes = cpu_to_le64(stfs.f_files);
 			info->FreeFileNodes = cpu_to_le64(stfs.f_ffree);
+			info->FileSysIdentifier =
+				cpu_to_le64((u64)(u32)stfs.f_fsid.val[1] << 32 |
+					    (u32)stfs.f_fsid.val[0]);
 			rsp->OutputBufferLength = cpu_to_le32(56);
 		}
 		break;
-- 
2.48.1

Re: [PATCH v3] ksmbd: fill in FileSysIdentifier in FS_POSIX_INFORMATION

[Namjae Jeon]

On Mon, Aug 24, 2026 at 11:40 PM Aleksandr Khromov <haa@amicon.ru> wrote:
>
> 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.
>
> Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3")
> Cc: stable@vger.kernel.org
> Signed-off-by: Aleksandr Khromov <haa@amicon.ru>
Applied it to #ksmbd-for-next.
Thanks!