[cifs-protocol] [EXTERNAL] Re: [REG:120063021002364] Clarification on length limit in SMB2_FILE_RENAME_INFORMATION filename
jra at samba.org
Mon Jul 13 18:29:48 UTC 2020
On Mon, Jul 13, 2020 at 05:18:45PM +0000, Obaid Farooqi wrote:
> Hi Jeremy:
> MS-SMB2 already addresses this issue from the client perspective. Please check out
> : In a SET_INFO request where FileInfoClass is set to FileRenameInformation, and the size of the buffer is less than 24, Windows clients pad the buffer to 24 bytes. These padding bytes are set to arbitrary values. Windows Vista SP1, Windows Server 2008, Windows 7, and Windows Server 2008 R2 clients append up to 4 additional padding bytes set to arbitrary values.
Ah yes, you're correct. Thanks for the reference.
A little hard to find though :-).
> The server side behavior is also documented in 188.8.131.52.1 ( https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-smb2/43cf22fe-84cb-49cf-b3e7-e3d7d766a7b7 )
> § If the size of the buffer is less than the size of FILE_RENAME_INFORMATION_TYPE_2 as specified in [MS-FSCC] section 184.108.40.206, the server MUST fail the request with STATUS_INFO_LENGTH_MISMATCH.
That's ambiguous though. Remember, different compilers
do structure packing different ways.
And [MS-FSCC] section 220.127.116.11
does *not* specify a total length. The last
field says "FileName (variable): A sequence of Unicode characters..".
The diagram shows the field to be 4 bytes, which
makes a minimum of 24, but the text (above) talks
about "A sequence of Unicode characters". One 2-byte
non-null terminated character fits within that
definition (with a total length of 22).
> The bug I have filed will make the server side behavior more crisp in the way mentioning 24 bytes (although client side already mentions that).
But yes, mentioning it also in the server side
will certainly help implementors.
More information about the cifs-protocol