Bug 7963 - smb2_util_roothandle() should set NameOffset in SMB2_CREATE to correct values
smb2_util_roothandle() should set NameOffset in SMB2_CREATE to correct values
Product: Samba 4.0
Classification: Unclassified
Component: smbtorture
x86 Windows 7
: P3 normal
: ---
Assigned To: Steven Danneman
: 7964 (view as bug list)
Depends on:
  Show dependency treegraph
Reported: 2011-02-18 12:51 UTC by Long Li
Modified: 2016-04-22 06:08 UTC (History)
2 users (show)

See Also:

fix (229 bytes, patch)
2016-04-21 22:06 UTC, Mostafa
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Long Li 2011-02-18 12:51:42 UTC
This was found by running SMBTorture test SMB2-GETINFO. In this test the client creates a SMB2_CREATE message with NameOffset set to 0. The client should set NameOffset to a correct value when opening a root share.

The following is taken from [MS-SMB2]

(In section 2.2.13 SMB2_CREATE Request)

NameOffset (2 bytes):  The offset, in bytes, from the beginning of the SMB2 header to the 8-byte aligned file name. If SMB2_FLAGS_DFS_OPERATIONS is set in the Flags field of the SMB2 header, the file name can be prefixed with DFS link information that will be removed during DFS name normalization as specified in section Otherwise, the file name is relative to the share that is identified by the TreeId in the SMB2 header. The NameOffset field SHOULD be set to the offset of the Buffer field from the beginning of the SMB2 header. The file name (after DFS normalization if needed) MUST conform to the specification of a relative pathname in [MS-FSCC] section 2.1.5. A zero length file name indicates a request to open the root of the share.
Comment 1 Volker Lendecke 2011-02-19 02:26:58 UTC
*** Bug 7964 has been marked as a duplicate of this bug. ***
Comment 2 Matthias Dieter Wallnöfer 2011-02-19 05:01:31 UTC
Steven, I'm assigning this up to you - as the other torture bugs.
Comment 3 Mostafa 2016-04-21 22:06:55 UTC
Created attachment 12015 [details]
Comment 4 Stefan Metzmacher 2016-04-22 06:08:21 UTC
Comment on attachment 12015 [details]

This seems to be some binary file