Tompkins, Michael
2021-May-10 15:54 UTC
[Samba] cli_smb2_dskattr() returning with NT_STATUS_INVALID_NETWORK_RESPONSE with blob length 65535
We have found that in one case we are getting: GetInfo Response (0x10) ... StructureSize: 0x0009 0000 0000 0000 1000. = Fixed Part Length: 4 .... .... .... ...1 = Dynamic Part: True Blob Offset: 0x00000048 Blob Length: 65535 In samba-4.7.5/source3/libsmb/cli_smb2_fnum.c, function: cli_smb2_dskattr() we see: 1943 /* getinfo on the returned handle with info_type SMB2_GETINFO_FS (2), 1944 level 3 (SMB_FS_SIZE_INFORMATION). */ 1945 1946 status = smb2cli_query_info(cli->conn, 1947 cli->timeout, 1948 cli->smb2.session, 1949 cli->smb2.tcon, 1950 2, /* in_info_type */ 1951 3, /* in_file_info_class */ 1952 0xFFFF, /* in_max_output_length */ 1953 NULL, /* in_input_buffer */ 1954 0, /* in_additional_info */ 1955 0, /* in_flags */ 1956 ph->fid_persistent, 1957 ph->fid_volatile, 1958 frame, 1959 &outbuf); 1960 if (!NT_STATUS_IS_OK(status)) { 1961 goto fail; 1962 } 1963 1964 /* Parse the reply. */ 1965 if (outbuf.length != 24) { 1966 status = NT_STATUS_INVALID_NETWORK_RESPONSE; 1967 goto fail; 1968 } 1969 So we decided to try change it to: + if (outbuf.length < 24) { + status = NT_STATUS_INVALID_NETWORK_RESPONSE; + goto fail; + } And the transfer passed. This was in 4.7.5 but we see the same logic exists in 4.12.x ... So do you think this is a valid change ? Is 65535 an expected valid return ? Is it indicating something ? Have you seen other cases where the blob length may not be 24 ? Your feedback would be great appreciated. Mike
Rowland penny
2021-May-10 16:27 UTC
[Samba] cli_smb2_dskattr() returning with NT_STATUS_INVALID_NETWORK_RESPONSE with blob length 65535
On 10/05/2021 16:54, Tompkins, Michael via samba wrote:> We have found that in one case we are getting: > GetInfo Response (0x10) > ... > StructureSize: 0x0009 > 0000 0000 0000 1000. = Fixed Part Length: 4 > .... .... .... ...1 = Dynamic Part: True > Blob Offset: 0x00000048 > Blob Length: 65535 > > In samba-4.7.5/source3/libsmb/cli_smb2_fnum.c, function: cli_smb2_dskattr() we see: > > 1943 /* getinfo on the returned handle with info_type SMB2_GETINFO_FS (2), > 1944 level 3 (SMB_FS_SIZE_INFORMATION). */ > 1945 > 1946 status = smb2cli_query_info(cli->conn, > 1947 cli->timeout, > 1948 cli->smb2.session, > 1949 cli->smb2.tcon, > 1950 2, /* in_info_type */ > 1951 3, /* in_file_info_class */ > 1952 0xFFFF, /* in_max_output_length */ > 1953 NULL, /* in_input_buffer */ > 1954 0, /* in_additional_info */ > 1955 0, /* in_flags */ > 1956 ph->fid_persistent, > 1957 ph->fid_volatile, > 1958 frame, > 1959 &outbuf); > 1960 if (!NT_STATUS_IS_OK(status)) { > 1961 goto fail; > 1962 } > 1963 > 1964 /* Parse the reply. */ > 1965 if (outbuf.length != 24) { > 1966 status = NT_STATUS_INVALID_NETWORK_RESPONSE; > 1967 goto fail; > 1968 } > 1969 > > So we decided to try change it to: > > + if (outbuf.length < 24) { > + status = NT_STATUS_INVALID_NETWORK_RESPONSE; > + goto fail; > + } > > And the transfer passed. This was in 4.7.5 but we see the same logic exists in 4.12.x ... So do you think this is a valid change ? Is 65535 an expected valid return ? Is it indicating something ? Have you seen other cases where the blob length may not be 24 ? Your feedback would be great appreciated. > > Mike >Can you try a 4.14.x version, the code appears to have changed, it is now 'status = cli_smb2_query_info_fnum' Rowland
Jeremy Allison
2021-May-17 18:10 UTC
[Samba] cli_smb2_dskattr() returning with NT_STATUS_INVALID_NETWORK_RESPONSE with blob length 65535
On Mon, May 10, 2021 at 03:54:36PM +0000, Tompkins, Michael via samba wrote:>We have found that in one case we are getting: > GetInfo Response (0x10) > ... > StructureSize: 0x0009 > 0000 0000 0000 1000. = Fixed Part Length: 4 > .... .... .... ...1 = Dynamic Part: True > Blob Offset: 0x00000048 > Blob Length: 65535 > >In samba-4.7.5/source3/libsmb/cli_smb2_fnum.c, function: cli_smb2_dskattr() we see: > >1943 /* getinfo on the returned handle with info_type SMB2_GETINFO_FS (2), >1944 level 3 (SMB_FS_SIZE_INFORMATION). */ >1945 >1946 status = smb2cli_query_info(cli->conn, >1947 cli->timeout, >1948 cli->smb2.session, >1949 cli->smb2.tcon, >1950 2, /* in_info_type */ >1951 3, /* in_file_info_class */ >1952 0xFFFF, /* in_max_output_length */ >1953 NULL, /* in_input_buffer */ >1954 0, /* in_additional_info */ >1955 0, /* in_flags */ >1956 ph->fid_persistent, >1957 ph->fid_volatile, >1958 frame, >1959 &outbuf); >1960 if (!NT_STATUS_IS_OK(status)) { >1961 goto fail; >1962 } >1963 >1964 /* Parse the reply. */ >1965 if (outbuf.length != 24) { >1966 status = NT_STATUS_INVALID_NETWORK_RESPONSE; >1967 goto fail; >1968 } >1969 > >So we decided to try change it to: > >+ if (outbuf.length < 24) { >+ status = NT_STATUS_INVALID_NETWORK_RESPONSE; >+ goto fail; >+ } > >And the transfer passed. This was in 4.7.5 but we see the same logic exists in 4.12.x ... > So do you think this is a valid change ? Is 65535 an expected valid return ? Is it > indicating something ? Have you seen other cases where the blob length may not be 24 ? > Your feedback would be great appreciated.Hi Mike, Looking at [MS-FSCC].pdf for the reply for FileFsSizeInformation I see: A FILE_FS_SIZE_INFORMATION data element, defined as follows, is returned by the server. ... TotalAllocationUnits AvailableAllocationUnits SectorsPerAllocationUnit BytesPerSector TotalAllocationUnits (8 bytes): A 64-bit signed integer that contains the total number of allocation units on the volume that are available to the user associated with the calling thread. This value MUST be greater than or equal to 0.<152> AvailableAllocationUnits (8 bytes): A 64-bit signed integer that contains the total number of free allocation units on the volume that are available to the user associated with the calling thread. This value MUST be greater than or equal to 0.<153> SectorsPerAllocationUnit (4 bytes): A 32-bit unsigned integer that contains the number of sectors in each allocation unit. BytesPerSector (4 bytes): A 32-bit unsigned integer that contains the number of bytes in each sector. The total here (8 + 8 + 4 + 4) == 24 bytes. If you're getting 65535 that's deeply strange. Can I ask what server are you talking to that returns this value (please don't say NetApp, I *hate* the NetApp implementation, it's so bad :-) :-). Do you have a wireshark trace you can share showing this ? There's nothing intrinsicly wrong with your change to ensure the return is at least 24 bytes, but I would like to know more before adding it. Can you log a bugzilla.samba.org bug so we can track this ? Thanks, Jeremy.