[cifs-protocol] [REG:120063021002364] Clarification on length limit in SMB2_FILE_RENAME_INFORMATION filename

Obaid Farooqi obaidf at microsoft.com
Mon Jul 6 18:18:54 UTC 2020

Hi Jeremy:
I'll help you with this issue and will be in touch as soon as I have an answer.

Obaid Farooqi
Escalatiion Engineer | Microsoft

-----Original Message-----
From: Bryan Burgin <bburgin at microsoft.com> 
Sent: Tuesday, June 30, 2020 4:29 PM
To: Jeremy Allison <jra at samba.org>; cifs-protocol at lists.samba.org
Cc: slow at samba.org; support <support at mail.support.microsoft.com>
Subject: [REG:120063021002364] Clarification on length limit in SMB2_FILE_RENAME_INFORMATION filename

[dochelp to bcc]

Hi Jeremy,

We created SR 120063021002364 To track this issue.  An engineer will contact you soon.


-----Original Message-----
From: Jeremy Allison <jra at samba.org> 
Sent: Tuesday, June 30, 2020 1:28 PM
To: Interoperability Documentation Help <dochelp at microsoft.com>; cifs-protocol at lists.samba.org
Cc: jra at samba.org; slow at samba.org
Subject: [EXTERNAL] Clarification on length limit in SMB2_FILE_RENAME_INFORMATION filename

Hi Dochelp,

A Samba user discovered a strange issue running the smbclient code against a Windows 10 server.

Trying to rename a file over SMB2 at the top level fails with NT_STATUS_INFO_LENGTH_MISMATCH if the target name is a single character.

E.g. renaming AAAA -> Z


The Samba SMB2 server accepts this rename request without complaint, as does the Windows 10 SMB1 server.

I've fixed this on the Samba client side by checking if the SMB2_FILE_RENAME_INFORMATION buffer size is less than 24 bytes, and padding out with zeros if this is the case.

The definition of SMB2_FILE_RENAME_INFORMATION shows the filename should be a variable-length non-null terminated UCS2 field, but it seems that a length of 2 is too short for the Windows server.

Any target name longer than this ends up with the SMB2_FILE_RENAME_INFORMATION being 24-bytes or greater, and the rename succeeds (so long as the name is a valid one).

It's not a 4-byte alignment issue, as I can vary the target name by adding characters and seeing the target buffer expand by 2 bytes per additional character.

I think Windows just has a hard check internally that the rename buffer must be >= 24 bytes, and the Windows client always pads to that.

It would be good to have a Windows behavior note confirming this.

Thanks !


More information about the cifs-protocol mailing list