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

Bryan Burgin bburgin at microsoft.com
Tue Jun 30 21:29:26 UTC 2020


[dochelp to bcc]
[+Support]

Hi Jeremy,

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

B.

-----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

returns NT_STATUS_INFO_LENGTH_MISMATCH.

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 !

Jeremy.



More information about the cifs-protocol mailing list