[Samba] cli_smb2_dskattr() returning with NT_STATUS_INVALID_NETWORK_RESPONSE with blob length 65535

[Tompkins, Michael]

Bugzilla Bug# 14709 created with attachments.

~Mike

-----Original Message-----
From: Jeremy Allison <jra at samba.org> 
Sent: Monday, May 17, 2021 2:11 PM
To: Tompkins, Michael <Michael.Tompkins at xerox.com>
Cc: samba at lists.samba.org; USA Xerox Samba <USA.Xerox.Samba at xerox.com>; jra at samba.org
Subject: Re: [Samba] cli_smb2_dskattr() returning with NT_STATUS_INVALID_NETWORK_RESPONSE with blob length 65535

CAUTION:   This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

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.