[Samba] cli_smb2_dskattr() returning with NT_STATUS_INVALID_NETWORK_RESPONSE with blob length 65535
Jeremy Allison
jra at samba.org
Mon May 17 18:10:34 UTC 2021
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.
More information about the samba
mailing list