[cifs-protocol] [REG:120063021002364] Clarification on length limit in SMB2_FILE_RENAME_INFORMATION filename
bburgin at microsoft.com
Tue Jun 30 21:29:26 UTC 2020
[dochelp to bcc]
We created SR 120063021002364 To track this issue. An engineer will contact you soon.
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
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.
More information about the cifs-protocol